Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address AVP
Carlos Pignataro <cpignata@cisco.com> Wed, 04 May 2005 16:50 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTN5C-0000sC-DD; Wed, 04 May 2005 12:50:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTN5A-0000ry-Ud; Wed, 04 May 2005 12:50:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28645; Wed, 4 May 2005 12:50:41 -0400 (EDT)
Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTNJI-0003zt-7a; Wed, 04 May 2005 13:05:21 -0400
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44GoVc03378; Wed, 4 May 2005 12:50:31 -0400 (EDT)
Received: from [64.102.51.195] (dhcp-64-102-51-195.cisco.com [64.102.51.195]) by rooster.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44GoVo21343; Wed, 4 May 2005 12:50:31 -0400 (EDT)
Message-ID: <4278FD56.5020005@cisco.com>
Date: Wed, 04 May 2005 12:50:30 -0400
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sasha Vainshtein <Sasha@AXERRA.com>
Subject: Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address AVP
References: <AF5018AC03D1D411ABB70002A5091326015E1E13@TLV1>
In-Reply-To: <AF5018AC03D1D411ABB70002A5091326015E1E13@TLV1>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79
Content-Transfer-Encoding: 7bit
Cc: Sharon Galtzur <sharon@AXERRA.com>, Elena Vinkler <elena@AXERRA.com>, "PWE3 WG (E-mail)" <pwe3@ietf.org>, l2tpext@ietf.org, Alik Shimelmits <alik@AXERRA.com>
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org
Sasha, Please see just a small couple of follow-up clarifications inline. Circa 5/4/2005 12:58 PM, Sasha Vainshtein said the following: > Carlos, > Please see more comments inline. > > Regards, > Sasha > > >> -----Original Message----- >> From: Carlos Pignataro [mailto:cpignata@cisco.com] >> Sent: Wednesday, May 04, 2005 5:24 PM >> To: Sasha Vainshtein >> Cc: Elena Vinkler; PWE3 WG (E-mail); l2tpext@ietf.org; Alik >> Shimelmits; >> Sharon Galtzur >> Subject: Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address AVP >> >> >> Sasha, >> >> Please see my comments inline. >> >> Circa 5/4/2005 11:16 AM, Sasha Vainshtein said the following: >> > Carlos and all, >> > I have checked the set of the "LDP PW Types" >> > as it appears in >> > >> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc >> ation-09.txt >> > vs. the set of "L2TP PW Types" as they appear in the drafts >> you refer to. >> > >> > Here are the results: >> > >> > >> > -------------------------------------------------------------------- >> > PW Type | LDP | L2TP | Comment >> > | value | value | >> > ---------------------|--------|--------|---------------------------- >> > Frame Relay DLCI | 0x0001 | 0x0001 | 0x0001 is a historic value >> > | | | for the original Martini >> > | | | encapsulation. >> > | 0x0019 | | 0x0019 is the value for the >> > | | | "standard" encapsulation. >> > | | | The need for this value >> > | | | has discovered recently >> > ----------------------|--------|--------|---------------------------- >> > ATM AAL5 SDU | 0x0002 | 0x0002 | >> > >> > ---------------------|--------|--------|----------------------------- >> > ATM Transparent Cell | 0x0003 | 0x0003 | >> > Transport | | | >> > ---------------------|--------|--------|----------------------------- >> > Ethernet VLAN | 0x0004 | 0x0004 | >> > ---------------------|--------|--------|----------------------------- >> > Ethernet | 0x0005 | 0x0005 | >> > ---------------------|--------|--------|----------------------------- >> > ATM N-to-1 VCC Cell | 0x0009 | 0x0009 | >> > Transport | | | >> > ---------------------|--------|--------|----------------------------- >> > ATM N-to-1 VPC Cell | 0x000a | 0x000a | >> > Transport | | | >> > ---------------------|--------|--------|----------------------------- >> > SAToP E1 | 0x0011 | TBA | >> > ---------------------|--------|--------| >> > SAToP T1 (DS1) | 0x0012 | TBA | >> > ---------------------|--------|--------| >> > SAToP E3 | 0x0013 | TBA | >> > ---------------------|--------|--------| >> > SAToP T3 (DS3) | 0x0014 | TBA | >> > ---------------------|--------|--------| >> > CESoPSN basic mode | 0x0015 | TBA | >> > ---------------------|--------|--------| >> > TDMoIP basic mode | 0x0016 | TBA | >> > ---------------------|--------|--------| >> > CESoPSN TDM with CAS | 0x0017 | TBA | >> > ---------------------|--------|--------| >> > TDMoIP TDM with CAS | 0x0018 | TBA | >> > --------------------------------------------------------------------- >> > >> > IMHO such a wonderful harmony (with the gaps in the L2TP PW Type >> > values matching LDP PW Types that are not supported over L2TP) >> > strongly suggests to me that the historical reasons work >> differently, >> > namely that the authors of the L2TP PW drafts have intentionally >> > aligned their allocation requests with these for the LDP PW Types\ >> > (existing since the early Martini drafts). And in doing so >> > they have successfully ignored the difference between >> > two octet values and 15-bit ones (look at the notaion used!) >> > >> > TDM PW types somewhat break this harmony, but hopefully this >> > will be fixed in the next revision of the dratf. >> >> I personally don't believe that the 15-bit vs. 2 octet is the only >> difference: Besides the TDM PW Types discrepancy that you noted, >> > [Sasha] To the best of my knowledge, this is an omission, not a > discrepancy: an earlier version of the draft has been posted > before the PW Types for the TDM PWs have been formally allocated, > and the consequent updates have simply missed the fact that > the allocation already exists. >> >> there are 2 LDP FR DLCI PW Types because of the FECN/BECN >> order reversal in the control word, problem that does not >> exist in L2TPv3; >> > [Sasha] As I have said, the need for two FR DLCI PW types > has been discovered only recently. Of course the problem > does not exist in L2TPv3. Personally I would say that two > PW Types are not really needed for LDP either and FECN/BECN > order in the CW could be easily signaled by a suitable > interface parameter (which, if omitted, would indicate > Martini order to assure backward compatibility) What I meant was that they do exist today for LDP. In consequence, IMHO, the absence of 1-to-1 mapping in the number space for the different protocols would complicate things when considering merging the registries. >> >> the ATM PW Types have actually a different name/description (and from >> draft-ietf-pwe3-iana-allocation-09.txt "description of up to 65 >> characters is required ...") >> > [Sasha] As much as I can see it, the difference is in the words > "n-to-one" (present in the PWE3 document and absent in the L2TPEXT > ones because no one cares for one-to-one encapsulations for > L2TPv3: whatever BW gain can be achieved, it is negligible once > the IP/L2TPv3 overhead is considered) To further clarify, the issue I see here as well is that the [1|n]-to-1 distinction is not present in L2TPv3 ATM draft, some ATM PW Types defined for LDP do not exist for L2TPv3, and thus would create another point of confusion. >> >> and the "one-to-one cell mode" are not >> defined in L2TPv3 ATM document (it probably wouldn't make sense to >> reference "n-to-one cell" PW Types from the L2TPv3 ATM document if >> that's not defined). So from the table above, it seems to me that only >> two PW Types are a true harmonic match. >> > [Sasha], Well, harmony (kind of beauty) is in the eye of the beholder... >> >> Also, the two number spaces have different allocation policies. >> > [Sasha] Is there any non-historical reason for that? I am not sure. However based on the current definition in RFC3931 and existing number space, limiting the `L2TPv3 PW Type' to 15 effective bits would effectively void the current FCFS range. Regards, --Carlos. >> >> > >> > So wouldn't it be better for all if the two name spaces were >> > merged by declaring that the two-octet value is treated >> > as a 16-bit integer in the network byte order, and the >> > LDP PW Type value is placed into least significant 15 bits? >> >> IMHO, merging the two name spaces would actually create a lot more >> confusion, not only because of the discrepancies mentioned above, but >> also because the L2TPv3 PW Type number space is already >> created as part >> of RFC3931, and L2TPv3 documents past last call already suggest values >> for IANA allocation in that number space. I believe the only >> place where >> the two spaces would meet is in the PW-IW case, in which case >> IMHO an IW >> consideration (and possibly the simplest) relates to the PW Type >> (further simplified in practice by the actual requested values) along >> with all other IW considerations. So it would seem to me that there is >> really not a specific problem for the current state. Let's see if >> there's other opinions. >> > [Sasha] The last suggestion is OK with me. >> >> Regards, >> >> --Carlos. >> >> > >> > IMHO this would save lots of unncessary trouble... >> > >> > Regards, >> > Sasha >> > >> >>-----Original Message----- >> >>From: Carlos Pignataro [mailto:cpignata@cisco./om] >> >>Sent: Wednesday, May 04, 2005 3:38 PM >> >>To: Sasha Vainshtein >> >>Cc: Elena Vinkler; PWE3 WG (E-mail); l2tpext@ietf.org; Alik >> >>Shimelmits; >> >>Sharon Galtzur >> >>Subject: Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address AVP >> >> >> >> >> >>Sasha, >> >> >> >>Please see a couple of comments inline. >> >> >> >>Circa 5/4/2005 6:19 AM, Sasha Vainshtein said the following: >> >> >> >>>Carlos and all, >> >>>Please see a brief comment inline. >> >>>CC'ing also the PWE3 WG >> >>>I have snipped the parts that are not relevant to this comment. >> >>> >> >>>Regards, >> >>> Sasha Vainshtein >> >>>e-mail: sasha@axerra.com >> >>>phone: +972-3-7659993 (office) >> >>>mobile: +972-52-8674833 >> >>> >> >>> >> >>> >> >>>>-----Original Message----- >> >>>>From: Carlos Pignataro [mailto:cpignata@cisco.com] >> >>>>Sent: Saturday, April 30, 2005 9:46 PM >> >>>>To: mark@mjlnet.com >> >>>>Cc: l2tpext@ietf.org >> >>>>Subject: Re: [L2tpext] Re: Local CE IP Address AVP >> >>>> >> >>> >> >>>... snipped ... >> >>> >> >>> >> >>>>>>For example, a PW Type for IP-L2 >> >>>>>>Transport is not yet defined (in any draft and thus not >> >>>>> >> >>>>>allocated), >> >>>>> >> >>>>>I thought that IP L2 transport had been allocated the PW type >> >>>>>0x000B, hadn't it?? >> >>>>> >> >>>> >> >>>>No. The link below Section 2. (or 2.1. in version -09) >> >> >> >>references the >> >> >> >>>>LDP (FEC128/129) "Pseudowire Type", which is a 15-bit >> >> >> >>quantity (1 bit >> >> >> >>>>used in the FEC Element for Control-word). >> >>>> IANA needs to set up a registry of "Pseudowire Type". >> >>>>These are 15- >> >>>> bit values. >> >>>> >> >>>>In contrast, "L2TPv3 Pseudowire Types" uses a different >> >>>>number space or >> >>>>registry created as part of RFC3931 (see Section 10.6) for >> >>>>these 16-bit >> >>>>quantities: >> >>>> The Pseudowire Type (PW Type, see Section 5.4) is a >> 2-octet value >> >>>> used in the Pseudowire Type AVP and Pseudowire >> >>>>Capabilities List AVP >> >>>> >> >>>>See also the registry "L2TPv3 Pseudowire Types" in >> >>>>http://www.iana.org/assignments/l2tp-parameters >> >>>> >> >>>>Regards, >> >>>> >> >>>>--Carlos. >> >>> >> >>>[Sasha] What are the reasons for keeping two different >> >>>name spaces for the same set of objects (PW Types)? >> >>>Just the different description of the format (2 octets >> >>>vs. 15-bit)? IMO it just adds unnecessary complexity. >> >> >> >>They are arguably two different sets of objects. RFC3931 defines the >> >>"L2TPv3 Pseudowire Type" (Section 10.6) as "a 2-octet value >> >>used in the >> >>Pseudowire Type AVP and Pseudowire Capabilities List AVP"; OTOH, >> >>although the reference [1] is missing in >> >>draft-ietf-pwe3-iana-allocation-09, it defines "Pseudowire >> >>Type" values >> >>to be used with draft-ietf-pwe3-control-protocol. >> >>The two spaces have different allocation policy as well. >> >>Why is it this way? I suppose the reasons are mostly historical, and >> >>while it may add complexity, it also keeps separation and >> >>adds flexibility. >> >> >> >> >> >>>E.g., consider the case of multi-segment PWs where >> >>>L2TPv3 segments must be stitched to MPLS segments with >> >>>the appropriate interworking of both data path and the >> >> >> >>control plane... >> >> >> >>In this case, the IWF should also contemplate the "L2TPv3 Pseudowire >> >>Type" <-> "Pseudowire Type" mapping, as another object to interwork. >> >> >> >> >> >>>The fact that no L2TP PW values have been allocated yet >> >> >> >>(I've checked >> >> >> >>>the registry before writing this email!) speaks for itself. >> >> >> >>RFC3931 defines the number space but not the values. From RFC3931: >> >> Defined PW types that may appear in this list are >> >>managed by IANA >> >> and will appear in associated pseudowire-specific >> documents for >> >> each PW type. >> >>... >> >> There are no specific pseudowire types >> >> assigned within this document. Each pseudowire-specific document >> >> must allocate its own PW types from IANA as necessary. >> >> >> >>And values are suggested in the respective companion documents: >> >>draft-ietf-l2tpext-pwe3-fr-05.txt >> >>draft-ietf-l2tpext-pwe3-hdlc-05.txt >> >>draft-ietf-l2tpext-pwe3-ethernet-03.txt >> >>draft-ietf-l2tpext-pwe3-atm-03.txt >> >>draft-ieft-l2tpext-tdm-00.txt >> >> >> >>The allocation of suggested values for "L2TPv3 Pseudowire Type" >> >>(included in those documents) was requested from IANA >> months ago. The >> >>fact the values do not appear in the registry may be just >> saying that >> >>there is a slow response from IANA. >> >> >> >>Best Regards, >> >> >> >>--Carlos. >> >> >> >> >> >>>... snipped to the end ... >> >>> >> >>> >> >>> >> >>> >> >>>... snipped to the end ... >> >>> >> >>>_______________________________________________ >> >>>pwe3 mailing list >> >>>pwe3@ietf.org >> >>>https://www1.ietf.org/mailman/listinfo/pwe3 >> >>> >> >> >> >>-- >> >>--Carlos. >> >>Escalation RTP - cisco Systems >> >> >> > >> > >> >> -- >> --Carlos. >> Escalation RTP - cisco Systems >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 -- --Carlos. Escalation RTP - cisco Systems _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3
- [PWE3] RE: [L2tpext] Re: Local CE IP Address AVP Sasha Vainshtein
- Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address … Carlos Pignataro
- RE: [PWE3] RE: [L2tpext] Re: Local CE IP Address … Sasha Vainshtein
- Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address … Carlos Pignataro
- RE: [PWE3] RE: [L2tpext] Re: Local CE IP Address … Sasha Vainshtein
- Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address … Carlos Pignataro
- RE: [PWE3] RE: [L2tpext] Re: Local CE IP Address … Yaakov Stein