The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] RE: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS WG concerns with G.8110.1 Amendment 1"
On Jun 29, 2007:1:19 PM, at 1:19 PM, Sasha Vainshtein wrote: > Italo and all, > Please see inline below. > > Regards, > Sasha > > > -----Original Message----- > From: Italo Busi [mailto:Italo.Busi@alcatel-lucent.it] > Sent: Friday, June 29, 2007 10:37 AM > To: Sasha Vainshtein; 'Yaakov Stein'; stbryant@cisco.com > Cc: mpls@lists.ietf.org; pwe3@ietf.org > Subject: RE: [mpls] RE: [PWE3] New Liaison Statement,"Response to PWE3 > and MPLS WG concerns with G.8110.1 Amendment 1" > > Sasha, > > when the issue was discussed during the approval phase of G.8110.1, > appendix III was added to G.8110.1 to clarify why T-MPLS reuses the > same > protocol number (e.g. EtherType) of MPLS and which are the > implications > for that. > > In particular this appendix clearly states that: > > " > When a pakcet is received on an Ethernet interface with EtherType > 0x8847, it is looked up in one particular label space as defined in > IETF > RFC 3031 section 3.4. > > The label manager is responsible for the allocation and reclamation of > the labels that are used within an MPLS or T-MPLS adaptation function. > " > [Sasha] The problem, IMHO, is that the existing "label managers" (used > by the MPLS label distribution protocols) are NOT aware of > this distinction since it is NOT part of the existing MPLS control > plane > specs. > The text you've quoted implicitly assumes that the MPLS control plane > (specified, implemented and deployed) and the T-MPLS management plane > MUST interwork properly (by splitting the label spaces) in order to > prevent T-MPLS being poisoned by MPLS or vice versa. This sounds like > imposing a new requirement on the MPLS control protocols designed > by the > IETF. > Did I miss something? > > Given this behavior, I cannot understand any real technical > argument in > favour of a different protocol number (e.g. EtherType). > > T-MPLS and MPLS have the same forwarding plane. As you have stated, > having the same forwarding plane (including the same protocol > number) is > facilitating MPLS/T-MPLS interworking. > > This is for me another good technical reason not to change the > protocol > number (e.g. EtherType). > > [Sasha] I am completely confused now. Are MPLS and T-MPLS supposed to > interwork, or not? > Please note also that the current designs for, say P2MP (multicast) > LSPs > use (to some extent) mapping of the protocol numbers to label spaces. > Hence using a separate protocol number for T-MPLS would be in line > with > the common trend. This is clearly what is the most ridiculous part here. If we just keep MPLS <= T-MPLS "interworking" or any other translation functions are a non-issue. Let us please keep things simple. --Tom > Best regards, Italo > >> -----Original Message----- >> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >> Sent: Thursday, June 28, 2007 8:18 AM >> To: Yaakov Stein; stbryant@cisco.com >> Cc: mpls@lists.ietf.org; pwe3@ietf.org >> Subject: RE: [mpls] RE: [PWE3] New Liaison Statement,"Response to >> PWE3 > >> and MPLS WG concerns with >> G.8110.1 Amendment 1" >> >> Yaakov, Stewart and all. >> >> IMHO the only real way to assure disjoint operation of MPLS and T- >> MPLS > >> is to allocate dedicated protocol numbers (EtherType etc.) for T- >> MPLS. >> Such an allocation would not harm T-MPLS in any way. >> >> On the contrary, to the best of my understanding, usage of the same >> protocol numbers cannot not serve any purpose beyond facilitating >> MPLS/T-MPLS interworking (be it intentional or not). >> >> So I suggest we resurrect our old proposal to SG15 to switch to a >> different set of protocol numbers. >> >> My 2c. >> >> Regards, >> Sasha >> >> >> -----Original Message----- >> From: Yaakov Stein [mailto:yaakov_s@rad.com] >> Sent: Thursday, June 28, 2007 9:07 AM >> To: stbryant@cisco.com >> Cc: mpls@lists.ietf.org; pwe3@ietf.org >> Subject: [mpls] RE: [PWE3] New Liaison Statement,"Response to PWE3 >> and > >> MPLS WG concerns with G.8110.1 Amendment 1" >> >> Stewart, >> >> If SG15's position is >> "The assumption we have made is that when deploying T-MPLS for this >> purpose >> it will be deployed on a network that is disjoint from any already >> deployed IP/MPLS network." >> then they should explicitly state a limitation in the scope >> section of > >> the new Recommendation. >> >> I recall several times when as editor I was forced to add such >> limitations. >> >> Something like >> "The protocol described in the Recommendation shall not be deployed >> in any existing IP/MPLS network, >> nor shall it interwork in any fashion with such a network." >> >> Y(J)S >> >> >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Tuesday, June 26, 2007 22:55 >> Cc: mpls@lists.ietf.org; pwe3@ietf.org >> Subject: Re: [PWE3] New Liaison Statement,"Response to PWE3 and MPLS >> WG concerns with G.8110.1 Amendment 1" >> >> The IETF response to our liaison of >> draft-ietf-pwe3-mpls-transport-00.txt >> was sent as a word document. To make sure that all members of PWE3 >> are > >> able to read it, I have extracted the substantive text as ASCII. >> >> I have major concerns about the assumption of disjoint operation >> since > >> I cannot see how the T-MPLS protocol prevents this. >> >> I request WG input on how to respond to this liaison. >> >> - Stewart >> >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|