RE: FW: I-D ACTION:draft-ietf-pwe3-satop-03.txt

Carlos, 

We (Yaakov and Sasha) would like to start our common response from 
addressing the last of your questions: 

<quote> 
        Why hide the presence of a L2-Specific Sublayer (CW) from 
        the control protocol (L2TPv3)? 
<end quote> 

>From our point of view, this question can be reversed: what could be 
GAINED by defining the SAToP Control Word (CW) as a (non-default) 
L2-sublayer and exposing it to the control protocol? 
Please note that: 
1. The SAToP CW MUST be present in the encapsulation, so there is no 
   need to signal its presence during the session establishment 
2. Default L2TPv3 sequencing mechanisms MUST NOT be used in any case 
   because sequencing for TDM PWs is quite different from that for 
   "traditional" L2 services: 
   - packets that arrive too late to be played out MUST count for lost 
   - lost packets MUST be compensated, byte for byte, with replacement 
     data 
   - packets arriving out of order SHOULD be re-ordered, instead of 
     being simply discarded 

And if no common L2TPv3 functional elements could be harnessed 
to serve the SAToP needs by exposing the SAToP CW to the control 
protocol, why should we bother defining a new L2-specific 
sublayer type (SAToP) and mandating presence of the corresponding 
AVP to indicate its presence? 

When in comes to usage/non-usage of the Length Field, please note 
that the draft (Section 4.3.1) defines its usage as OPTIONAL: 
<quote> 
  LEN (bits (10 to 15) MAY be used to carry the length of the SAToP 
  packet (defined as the size of the SAToP header + the payload size) if 
  it is less than 64 bytes, and MUST be set to zero otherwise. When the 
  LEN field is set to 0, the preconfigured size of the SAToP packet 
  payload MUST be assumed, and if the actual packet size is inconsistent 
  with this length, the packet MUST be considered to be malformed. 
<end quote> 
Since the proposed field does not require any additional bits in the CW, 
we do not see the purpose of omitting it.

Last but not least, we see a substantial advantage in using exactly 
the same SAToP CW format for all types of PSN and demultiplexing. 
In particular (and this point has been instrumental in accepting the 
proposal to reverse the CW and RTP header order in spite of having a 
working implementation) it facilitates effortless interworking between 
MPLS and L2TPv3 SAToP PW segments (including VCCV interworking). 
Unfortunately, interworking with UDP/IP is more complex.

Regarding your second point
<quote>
   Why does the CW for L2TPv3 use a nibble for VCCV discrimination, and
   not just 1 bit (as in [VCCV] for the Default L2SS)? There are no ECMP
   avoidance considerations for L2TPv3 as transport. 
<end quote>

Once again, the ability to enable simple interoperation between MPLS 
and L2TPv3 based PWs is the important feature here. 

To conclude, the SAToP draft update was mainly directed at complying 
with the proposal agreed upon at the breakout meeting regarding 
reversal of order of the CW and RTP header (if the latter is used) 
for SAToP PWs over L2TPv3.  We do not see any reason to reverse the 
agreement reached early on in the TDM PW work to use the standard 
PWE control word even in the L2TPv3 case.


Regards, 
                        Yaakov and Sasha 

> -----Original Message-----
> From: Carlos Pignataro [mailto:[email protected]]
> Sent: Wednesday, September 28, 2005 6:31 PM
> To: Sasha Vainshtein
> Cc: Stewart Bryant (E-mail); Danny McPherson (E-mail); Mark Townsley
> (E-mail); Yaakov Stein (E-mail); PWE3 WG (E-mail); L2tpext Wg (E-mail)
> Subject: Re: FW: [PWE3] I-D ACTION:draft-ietf-pwe3-satop-03.txt
> 
> 
> Hello Sasha,
> 
> What was the conclusion on these three items raised in later emails in
> that same thread, for the case when using L2TPv3 demux? The relevant
> text in the draft is unchanged:
> 1. Why does the CW for L2TPv3 contain a Length field? It is only
>    specific to MPLS as transport and not to L2TPv3 as transport nor to
>    the PW Type itself.
> 2. Why does the CW for L2TPv3 use a nibble for VCCV 
> discrimination, and
>    not just 1 bit (as in [VCCV] for the Default L2SS)? There 
> are no ECMP
>    avoidance considerations for L2TPv3 as transport. Between items 1.
>    and 2. there are 9 bits that are not applicable.
> 3. Why hide the presence of a L2-Specific Sublayer (CW) from 
> the control
>    protocol (L2TPv3)? From RFC3931, between the L2TP Session 
> Header and
>    the transported payload itself, the L2SS intermediary 
> layer is to be
>    signaled (L2SS AVP enumerations), and a PW-Specific (i.e.,
>    SAToP|TDM-Specific non-default) Sublayer can be defined.
> 
> Thanks,
> 
> --Carlos.
> 
> Circa 9/17/2005 5:10 AM, Sasha Vainshtein said the following:
> > Hi all,
> > 
> > Following the discussion at the PWE3 VCCV break-out meeting,
> > (see 
> http://www1.ietf.org/mail-archive/web/pwe3/current/msg07437.html),
> > Yaakov and I have updated the SAToP draft accordingly and 
> posted its -03
> > revision.
> > 
> > Regards,
> > 				Sasha
> > 
> > 
> >>-----Original Message-----
> >>From: [email protected] [mailto:[email protected]]
> >>Sent: Thursday, September 15, 2005 9:50 PM
> >>To: [email protected]
> >>Cc: [email protected]
> >>Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-satop-03.txt 
> >>
> >>
> >>A New Internet-Draft is available from the on-line 
> >>Internet-Drafts directories.
> >>This draft is a work item of the Pseudo Wire Emulation Edge 
> >>to Edge Working Group of the IETF.
> >>
> >>	Title		: Structure-Agnostic TDM over Packet (SAToP)
> >>	Author(s)	: S. Vainshtein, Y. Stein
> >>	Filename	: draft-ietf-pwe3-satop-03.txt
> >>	Pages		: 19
> >>	Date		: 2005-9-15
> >>	
> >>This document describes a pseudowire encapsulation for TDM 
> >>(T1, E1, T3, 
> >>E3) bit-streams that disregards any structure that may be 
> imposed on 
> >>these streams, in particular the structure imposed by the 
> >>standard TDM 
> >>framing.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-03.txt
> >>
> >>To remove yourself from the I-D Announcement list, send a 
> message to 
> >>[email protected] with the word unsubscribe in 
> >>the body of the message.  
> >>You can also visit 
> >>https://www1.ietf.org/mailman/listinfo/I-D-announce 
> >>to change your subscription settings.
> >>
> >>
> >>Internet-Drafts are also available by anonymous FTP. Login 
> >>with the username
> >>"anonymous" and a password of your e-mail address. After logging in,
> >>type "cd internet-drafts" and then
> >>	"get draft-ietf-pwe3-satop-03.txt".
> >>
> >>A list of Internet-Drafts directories can be found in
> >>http://www.ietf.org/shadow.html 
> >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>
> >>Internet-Drafts can also be obtained by e-mail.
> >>
> >>Send a message to:
> >>	[email protected].
> >>In the body type:
> >>	"FILE /internet-drafts/draft-ietf-pwe3-satop-03.txt".
> >>	
> >>NOTE:	The mail server at ietf.org can return the document in
> >>	MIME-encoded form by using the "mpack" utility.  To use this
> >>	feature, insert the command "ENCODING mime" before the "FILE"
> >>	command.  To decode the response(s), you will need "munpack" or
> >>	a MIME-compliant mail reader.  Different MIME-compliant 
> >>mail readers
> >>	exhibit different behavior, especially when dealing with
> >>	"multipart" MIME messages (i.e. documents which have been split
> >>	up into multiple messages), so check your local documentation on
> >>	how to manipulate these messages.
> >>		
> >>		
> >>Below is the data which will enable a MIME compliant mail reader
> >>implementation to automatically retrieve the ASCII version of the
> >>Internet-Draft.
> >>
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> -- 
> --Carlos.
> Escalation RTP - cisco Systems
>