Subject: RE: AD review of draft-ietf-pwe3-cw-01.txt - comment 5

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 20 Feb 2005 18:36:52 +0200

> Stewart and all,
> Please note that TDM PWs do not require this mechanism 
> because the size of the PW packet is defined during the setup.
> 
> So I suggest to change MUST to SHOULD and add the appropriate 
> qualifier e.g. "TDM PWs represent a known exception becaues 
> their packets all have the same size defined at the PW 
> setup". A reference to Section 6.1 of the TDM Requirements 
> document (which states that the common PWE3 requirement to 
> support variable length PDUs does not apply to TDM
> PWs) would be also in place ere.

Sasha- 

Please note that what you said is ONLY for SAToP
and even THEN it is a major limitation.

For TDMoIP the packet size may change from packet
to packet in AAL2 mode and CCS mode. 
In CESoPSN the packet size
may change if inband CAS is used.

Even for SAToP, only the end points know what the
size should be. If we want to change lower layers,
e.g. from Ethernet to POS in the middle of the network, 
the IWF will not know how the size was configured,
and will need to know how much padding to remove.
For this reason even SAToP needs the length indication.

For all these reasons it is CRITICAL to have 
the length in TDM PW packets.

Stewart - I would actually prefer the original wording
as that is how our implementation works.
We check the payload + CW + optional RTP + PW label 
and knowing the PSN type we calculate the size. 

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 21 Feb 2005 01:34:23 -0800 (PST)

Yaakov and all,
My office emailer still is out of order when it comes to sending emails to the PWE3 list, so I respond using my personal account.
 
I would like to start with one general comment, and then will add a few comments inline.
A general comment: 
 
The LEN field of the preferred CW is not the only or even the ultimate source of information abut the size of the PW packet payload. In fact, it is only used when this information cannot be learned in any other way. E.g., 

IF 

   the service carried across the PW uses variable size PDUs

AND

   the specific PDU of this serviceis so short that its actual size cannot be unambiguously defined from the size of the Layer 2 frame as received by the peer PE

THEN 

   this size will be defined using the information carried in the LEN field of the preferred CW.

Please note that there is nothing TDM-specific in the statement above.

Now, when you come to TDM PWs, the receiver can, in most cases, deduce the size of the PW payload without appealing to the LEN field prop:

   In some cases this size is simply known from the very beginning (SAToP or CESoPSN  for basic NxDS0)
   In other cases it can be unambiguously deduced by other means (CESoPSN for trunk-specific NxDS0 with CAS or AAL1-mode of TDMoIP where the the payload size is a multiple of 48 bytes). 

So I would argue that in all these cases usage of the LEN field is not required (but, of course, is not prohibited either).

Please see also a few specific comments inline below.

Regards,

                             Sasha Vainshtein

email: [email-masked]

          [email-masked]

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Sunday, February 20, 2005 6:37 PM
> To: Sasha Vainshtein; Stewart Bryant; Ronen Shaashoua; Ron Insler
> Cc: pwe3; 'Riegel Maximilian' (E-mail); Alik Shimelmits
> Subject: RE: [PWE3] AD review of draft-ietf-pwe3-cw-01.txt - comment 5
> 
> 
> 
> > Stewart and all,

[Sasha] I do not think that the AAL2 mode of TDMoIP represents a TDM PW because it is optimized to carrying bundeld Voice services. AFAIK, the ITU-T has taken similar position on this issue by splitting "TDM-MPLS network interworking - User plane interworking" to Y.1413 and "Voice services - MPLS network interworking" - to Y.1414. But, of course, this is my personal opinion, and I do not have any problem with making the LEN field mandatory for the AAL2 mode of TDMoIP.
> For this reason even SAToP needs the length indication.

[Sasha] Sorry, I do not follow you. IMHO, usage (or non-usage) of the LEN field does not have anything in common with any actual Layer 2 media that can be crossed by a PW packet between the two end points. Its usage simply takes into account a potential worst case of padding that possibly could have been added by one or more Ethernet links. In case of SAToP, the payload size is fixed while the size of the L2 frame carrying it may vary for many reasons (e.g., different media, changes in the depth of the label stack etc.). But these changes are completely irrelevant for the IWF operation.
> and knowing the PSN type we calculate the size. 

[Sasha] This does not mean to me that ALL implementations MUST do that.

And this is not, IMO, what the origianl wording implied.

Nor do I understand what do you mean by "knowing the PSN type".
> Y(J)S

Regards,
                     Sasha Vainshtein
email:               [email-masked]
                     [email-masked]
phone:               +972-3-7659993  (office)
                     +972-52-8674833 (mobile)
		
---------------------------------
Do you Yahoo!?
 Yahoo! Search presents - Jib Jab's 'Second Term'

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 22 Feb 2005 18:24:35 +0200

Regards,
                                  Sasha Vainshtein
email:                          <mailto:[email-masked]> [email-masked]
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833 

-----Original Message-----
From: Sasha Vainshtein 
Sent: Tuesday, February 22, 2005 6:23 PM
To: 'Yaakov Stein'
Cc: [email-masked]; [email-masked]; Alik Shimelmits;
[email-masked]; Ronen Shaashoua; Ron Insler
Subject: RE: FW: [PWE3] AD review of draft-ietf-pwe3-cw-01.txt - comment 5

Yaakov and all,
Please see some comments inline below (bold maroon).
 
Regards,
                                  Sasha Vainshtein
email:                          <mailto:[email-masked]> [email-masked]
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833 

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Tuesday, February 22, 2005 10:47 AM
To: Sasha Vainshtein
Cc: [email-masked]; [email-masked]; Alik Shimelmits;
[email-masked]; Ronen Shaashoua; Ron Insler
Subject: RE: FW: [PWE3] AD review of draft-ietf-pwe3-cw-01.txt - comment 5

Sasha, 
 
I completely agree with your general comment:  
but we perhaps differ on the specifics.
 
 [Sasha] I do not think that the AAL2 mode of TDMoIP represents a TDM PW
because it is optimized to carrying bundeld Voice services. AFAIK, the ITU-T
has taken similar position on this issue by splitting "TDM-MPLS network
interworking - User plane interworking" to Y.1413 and "Voice services - MPLS
network interworking" - to Y.1414. But, of course, this is my personal
opinion, and I do not have any problem with making the LEN field mandatory
for the AAL2 mode of TDMoIP. 
 
The ITU handled Y.1413 and Y.1414 as different for various (political)
reasons,
which have little to do with the definition of TDM PWs.
Similarly, here we treat SAToP, CESoPSN and TDMoIP as three different
documents, although all three are TDM PWs.
 
In my opinion, except for SAToP (which blindly chops off N bytes)
all the encapsulations mangle the original TDM frames to some extent.
Once we chop off the FAS and regenerate it, 
or separate the CAS sigaling bits and reinsert them,
we are performing a circuit emulation, and not just a simple transport
function.
 
So where do we draw the line?
What if you were to reorder the bytes for some reasons,
sending the odd ones first and then the even ones.
Would you then say that this is no longer a TDM PW?
In my view this is less infringing than NOT sending the FAS
and making one up! 
[Sasha] I think the following experiment can be helpful in drawing the line:
If the given emulation method preserves ability to carry two different
applications
(e.g. Voice and HDLC, or, say, Voice and combined Voice/Video) over the PW,
it is a 
TDM PW. If it suits just one application, it is not. 
 
IMHO, SAToP, CESoPSN and TDMoIP in its AAL1 mode all pass this test (this is
based
on direct experiments in the first two cases and looks like a valid
assumption to me 
in the third case). I do not know if TDMoIP in its AAL2 mode would pass such
a test or not.
 
In the AAL2 mode we pull bytes from various timeslots and send
them together, and then put them back in order at the other end.
This in no way changes the fact that we are emulating the original
TDM link! It is merely a method of making it more efficient to
be able to dynamically allocate timeslots.

[Sasha] Sorry, I do not follow you. IMHO, usage (or non-usage) of the LEN
field does not have anything in common with any actual Layer 2 media that
can be crossed by a PW packet between the two end points. Its usage simply
takes into account a potential worst case of padding that possibly could
have been added by one or more Ethernet links. In case of SAToP, the payload
size is fixed while the size of the L2 frame carrying it may vary for many
reasons (e.g., different media, changes in the depth of the label stack
etc.).  
 
That is precisely the problem.
Think of the following situation. A 30-byte SAToP packet 
is sent over an Ethernet link. It is of course padded.
Somewhere in the middle of the network the L2 is changed
to another medium which does not require the padding.
and in a more interesting case, would be able to carry the
original packet efficiently, but requires much larger bandwidth
for the padded one (since we exceed some chunk size or other).
A PW-aware media converter would be able to remove the padding
based on the PW CW length field, if it is used.
[Sasha] To the best of my knowledge, a "PW-aware media converter" definitely
does
not exist in the current PWE3 architecture. Nor do I remembre it being
discussed as
part of the MH-PW extension. As a consequence, I think that setting the LEN
field to
a specific value even in the case of PWs that do not require it OPTIONAL:
the transmitter
MAY set it, and the receiver, if it receives such packets, MAY use this
information to detect
malformed packets.
I also have a more general point.
It would be nice if nonzero length and padding were perfectly correlated
(i.e. every time we have a nonzero length there is padding,
and every time we have padding there is a nonzaero length)
but this is not always possible inside the network due to labels
being pushed and popped.
However, at the end points where we know the size of the 
PSN headers, it would be nice for this to be the case. 
[Sasha] IMHO this is only possible in the case of an IP PSN. 

I never implied they should. All I said is that for between 46 and 63
I prefer the MAY transmit and MUST receive wording.  
 
[Sasha] I'd say that for PWs that support variable size PDUs and do not
allow
deduction of the payload size by other means (e.g., ATM many-to-one
Cell PW services with packing with multiple cells packet into a single
packet),
both setting and reception are MUST.  And this is how the L2 encap drafts
treat it.
But one  point is, IMO, missing. It is related to detection of
malformed packets. IMO, two cases should be considered for the PWs where
variable size PDUs are supported and the granularity of the payload size
precludes
alternatives:
1. A LONG L2 frame (exceeding any possible padding effects) has been
received, but
   the LEN field has been set to some non-zero value. Today the
encapsulation drafts
   state that you should trust the LEN field and ignore the frame size
 
2. A SHORT (below 64 bytes) L2 frame has been received but the LEN field is
0.
   IMHO this should be treated as a malformed packet.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 22 Feb 2005 11:21:56 +0200

Sasha, 

 [Sasha] I do not think that the AAL2 mode of TDMoIP represents a TDM PW
because it is optimized to carrying bundeld Voice services. AFAIK, the
ITU-T has taken similar position on this issue by splitting "TDM-MPLS
network interworking - User plane interworking" to Y.1413 and "Voice
services - MPLS network interworking" - to Y.1414. But, of course, this
is my personal opinion, and I do not have any problem with making the
LEN field mandatory for the AAL2 mode of TDMoIP. 

 

[Sasha] Sorry, I do not follow you. IMHO, usage (or non-usage) of the
LEN field does not have anything in common with any actual Layer 2 media
that can be crossed by a PW packet between the two end points. Its usage
simply takes into account a potential worst case of padding that
possibly could have been added by one or more Ethernet links. In case of
SAToP, the payload size is fixed while the size of the L2 frame carrying
it may vary for many reasons (e.g., different media, changes in the
depth of the label stack etc.).  

 

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 23 Feb 2005 20:34:39 +0200

[Sasha] I do on understand your reference to "Channelized TDM".
Do you mean that if you run HDLC over a bundle of timeslots
(not a separate HDLC flow per TS!) and pass this bundle 
through a PW using the AAL2 mode of TDMoIP, 
HDLC would still be OK at the other side of the PW? 
 
Absolutely.

In my opinion the PW IWF MUST assume that all tunnel labels
have been removed. Otherwise we have a clear layer violation.
[Sasha] IMHO this is an implementation issue, the PW IWF
simply must know where the PW part (after the PW label) starts
and how many bytes it spans. And as far as layer violations are
concerned, I'd say that the IWF should not be interested in the PW
label as well - it is only required for demultiplexing, not for
interworking. 
 
The padding functionality is a pure Ethernet function,
and shouldn't be handled by the PW encapsulator.
In fact, the PW encapsulator shouldn't have to know
whether it the lower layer will be Ethernet or something else.

In any case,  this wording says something
else too - if there is a zero length field, then there is no padding!
We find this same wording in all the drafts - 
if the entire packet needs padding, then there MUST 
So if this is authoritative, it goes against your thesis. 
[Sasha] Bearing in mind my previous comment on "the other drafts", I'd
say that this is a common bug. 
 
Bug is in the eye of the beholder :>

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 23 Feb 2005 17:47:09 +0200

Sasha, 
 
Since the emails have become unwieldly, I will just snip the parts
I want to discuss.
 
----------------------------------------------------------------
[Sasha]  Sorry, but I do not think this answers my question: if
subjected to 
 the test I have proposed, shall the AAL2 mode of TDMoIP pass it, or
shall it not? 
 
Of course it does for channelized TDM.
The AAL2 mechanism couldn't care what is in the channels.
However, based on the channel content you can add advanced features.
 
----------------------------------------------------------------
[Sasha]  The PW de-capsulator should not, IMHO, assume that the tunnel
label has been
popped (or has not been popped) as this may vary.  But presumably it
could inspect the entrire
label stack to find the bottom label and the CW.  

----------------------------------------------------------------
[Sasha]  IMHO (we should ask the authors) this is why the lower-case
"must" is
used in this fragment, while the IETF capitalized MUST states that the
LEN
field is set if the size of the payload + the size of the CW is <= 63
bytes
(and hence is potentially, but not necessarily, paddable). 
 
Look at the HDLC draft. There it is a MUST not a must.
So I doubt that there is deep meaning to this lack of capitalization.
Authors ??
 
[Sasha]  The TDM PWs (at least ones using fixed size payload)  can do
with
MAY instead of MUST.  
That means only SAToP, since all the others have exceptions to the rule.

----------------------------------------------------------------
[Sasha] The following is a quote from the latest FR encap draft
(http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-04.txt)
:
<quote>
7.7.2. Processing of the Length Field by the Receiver

   Any padding octet, if present, in the payload field of a PW packet
   received MUST be removed before forwarding the data.
     - If the Length field is set to zero then there are no padding
       Characters following the payload field.
     - Else if the payload is longer then the length specified in the
       control word padding characters are removed based on the length
       field.
<end quote>
It does not say anything about the packet itslef being short or long,
just "if the LEN field is set, trust it".
I also would prefer treating the case described here as a malformed
packet, and reported this to the list. But the authors of the draft
presumably do not think so. 
 
As I said in a separate email, I believe the handling of padding
in the FR draft (and in X.84 version) is incorrect. 
The padding should NOT be a function of the PW IWF (once again a layer
violation).
Also, we don't see similarly wording in the other drafts.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 23 Feb 2005 12:18:19 +0200

Yaakov,
Please see more inline (bold purple this time).
 
Regards,
                                  Sasha Vainshtein

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, February 23, 2005 11:59 AM
To: Sasha Vainshtein
Cc: [email-masked]; [email-masked]; Alik Shimelmits;

Sasha, 

----------------------------------------------------------------
[Sasha]  Sorry, but I do not think this answers my question: if subjected to

 the test I have proposed, shall the AAL2 mode of TDMoIP pass it, or shall
it not? 

----------------------------------------------------------------
[Sasha]  The PW de-capsulator should not, IMHO, assume that the tunnel label
has been
popped (or has not been popped) as this may vary.  But presumably it could
inspect the entrire
label stack to find the bottom label and the CW.  

----------------------------------------------------------------
[Sasha]  IMHO (we should ask the authors) this is why the lower-case "must"
is
used in this fragment, while the IETF capitalized MUST states that the LEN
field is set if the size of the payload + the size of the CW is <= 63 bytes
(and hence is potentially, but not necessarily, paddable). 

[Sasha] I can only join your call to the authors and suggest that these
issues should be preferably written once (say, in the CW draft?) and not
replicated with variations in each encapsulation draft... 
And as for looking at the HDLC/PPP draft, it has expired. I hope it has been
re-posted with the latest bunch of the WG drafts and slowly makes its way
through the pre-meeting I-D jam.

[Sasha]  The TDM PWs (at least ones using fixed size payload)  can do with
MAY instead of MUST.  
That means only SAToP, since all the others have exceptions to the rule.  

[Sasha] Trunk-specific NxDS0 with CAS in CESoPSN can use the FRG bits
to define if the signaling structure has been added or not. And AAL1 mode
of TDMoIP can use the "multiples of 48" rule. But I believe that we are
converging
here. 

----------------------------------------------------------------
[Sasha] The following is a quote from the latest FR encap draft
( http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-04.txt
<http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-04.txt> ):
<quote>
7.7.2. Processing of the Length Field by the Receiver

   Any padding octet, if present, in the payload field of a PW packet
   received MUST be removed before forwarding the data.
     - If the Length field is set to zero then there are no padding
       Characters following the payload field.
     - Else if the payload is longer then the length specified in the
       control word padding characters are removed based on the length
       field.
<end quote>
It does not say anything about the packet itslef being short or long, just
"if the LEN field is set, trust it".
I also would prefer treating the case described here as a malformed packet,
and reported this to the list. But the authors of the draft presumably do
not think so. 
 
As I said in a separate email, I believe the handling of padding
in the FR draft (and in X.84 version) is incorrect. 
The padding should NOT be a function of the PW IWF (once again a layer
violation). 
[Sasha] I agree that padding is not the PW IWF function. But please note
that
I was quoting the latest FR draft where padding has been removed by Luca. 
Also, we don't see similarly wording in the other drafts. 
[Sasha] Which ones? With the HDLC draft expired, this only leaves AAL5 mode
of the ATM draft.
And it is conveniently silent wrt the LEN field processing. 
 
In any case,  this wording says something
else too - if there is a zero length field, then there is no padding!
We find this same wording in all the drafts - 
if the entire packet needs padding, then there MUST 
So if this is authoritative, it goes against your thesis. 
[Sasha] Bearing in mind my previous comment on "the other drafts", I'd say
that this is a common bug.
 
Y(J)S