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

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 4 May 2005 17:16:15 +0200

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-allocation-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.

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 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); [email-masked]; 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:		[email-masked]
> > phone:		+972-3-7659993 (office)
> > mobile:		+972-52-8674833
> > 
> > 
> >>-----Original Message-----
> >>From: Carlos Pignataro [mailto:[email-masked]]
> >>Sent: Saturday, April 30, 2005 9:46 PM
> >>To: [email-masked]
> >>Cc: [email-masked]
> >>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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> -- 
> --Carlos.
> Escalation RTP - cisco Systems
> 

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

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 04 May 2005 11:23:51 -0400

Sasha,

Please see my comments inline.

> vs. the set of "L2TP PW Types" as they appear in the drafts you refer to.

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, 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; 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 ...") 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. Also, the two number spaces have
different allocation policies.

> 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.

Regards,

--Carlos.