Re: [PWE3] RE: [L2tpext] Re: Local CE IP Address AVP

[Carlos Pignataro <[e-mail]>]

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:[e-mail]]
>> Sent: Wednesday, May 04, 2005 5:24 PM
>> To: Sasha Vainshtein
>> Cc: Elena Vinkler; PWE3 WG (E-mail); [e-mail]; 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); [e-mail]; 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:            [e-mail]
>> >>>phone:             [phone] (office)
>> >>>mobile:            [phone]
>> >>>
>> >>>
>> >>>
>> >>>>-----Original Message-----
>> >>>>From: Carlos Pignataro [mailto:[e-mail]]
>> >>>>Sent: Saturday, April 30, 2005 9:46 PM
>> >>>>To: [e-mail]
>> >>>>Cc: [e-mail]
>> >>>>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
>> >>>[e-mail]
>> >>>https://www1.ietf.org/mailman/listinfo/pwe3
>> >>>
>> >>
>> >>--
>> >>--Carlos.
>> >>Escalation RTP - cisco Systems
>> >>
>> >
>> >
>>
>> --
>> --Carlos.
>> Escalation RTP - cisco Systems
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext