RE: decisions on L2 solutions documents

[email protected] Mon, 2 Jun 2003 22:30:32 +0100
Newsgroups gmane.ietf.ppvpn
Message-ID <0536FC9B908BEC4597EE721BE6A35389025D6934@i2km07-ukbr.domain1.systemhost.net>
Hamid Ould-Brahim wrote 02 June 2003 18:35

Peter, 
> 
> 
> Wouldn't it be kind of cool if we could use the same 
> addressing format for 
> what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to 
> say we always 
> identify the end-point of an LSP/PW/tunnel with a unique 
> address (I mean 
> unique for the LSP/PW/tunnel so no 2 PWs share the same address)? 
> 
But it that case how about pw created for l2vpns.
NH=> Hamid why do you think you need PWs at all?  The only reasons PWs exist
is as follows:
-	to fix the problems caused by mp2p LSPs.....if you want any-any
connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp
constructions make any arch sense....mp2p leads to problems and kludges;
-	to keep the pretence-up that MPLS =~ IP.....if true why do we need
MPLS then?  Use the right mode for the right application....both are
required;
-	to squeeze a bit of the server-layer BW via client compression (a
total non-issue IMO when other technolgies squander BW).

Would these 
addresses be required to be always unique or can be 
overlapping?  
NH=> PWs are *not* a layer network....they are actually a set of
encapsulation functions that belongs in the client->server adaptation
process (network-interworking case).  Client->server adaptation should be a
minimalist mapping with (ideally) no functions that need management (eg
sequence number aberrations).  PWs don't need addresses, ie PWs are not
switched network entities like LSPs...its MPLS that needs access point
addresses in its own right since MPLS creates a layer network.  Further,
when one considers mixed partition service-interworking between technologies
belonging to the *same* network mode (eg FR_access<=>MPLS_core<=>ATM_access)
PWs simply disappear anyway.  I know service-interworking is not on IETF's
(PWE3) agenda, but speaking as an operator its very high on ours to drive
down capex/opex so we can have a common core per network mode.....so please
(as a vendor) don't ignore it.

Its the above issues that sit behind Peter's original comments.

regards, Neil