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