RE: decisions on L2 solutions documents
[email protected] Tue, 3 Jun 2003 13:44:33 +0100
| Newsgroups | gmane.ietf.ppvpn |
|---|---|
| Message-ID | <0536FC9B908BEC4597EE721BE6A35389025D6947@i2km07-ukbr.domain1.systemhost.net> |
Giles, > > > > > > 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). > [rest snipped] > > Meanwhile, back in the real world, PWs (in the MPLS context) do the > following: > > 1) add a label to the stack to keep state out of the core > (this may also > create a p2p LSP on top of an mp2p LSP, depending on whether you are > using LDP or RSVP-TE for your tunnel LSPs). NH=> This is an LSP issue and belongs to the proper MPLS layer network....nothing to do with PWs. > 2) create a bidirectional p2p construct out of two unidirectional p2p > LSPs. NH=> This is an LSP issue and belongs to the proper MPLS layer network....nothing to do with PWs. > 3) adapt the layer 2 protocol being carried to MPLS. NH=> Now you have it....PW are about adaptation....with that I agree. > This involves > three things: > i. stripping off the layer 2 header (aka "compression") in the cases > such as FR where the header may be different at each end. NH=> Yep, bit of BW squeezing > ii. sequence numbering, if required, for the case where the core > network may reorder packets. NH=> Yep, there to fix lower layer MPLS problems. > iii. length checking, for the case where the core network's > minimum PDU > is larger than that of the PW (this is required because MPLS has no > length field). NH=>Agreed, adaptation function should pad to minimum. > > Giles > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > >