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

Sasha, Yaakov,

Thank you for your response.

Regarding the reversed question "what could be GAINED by defining the
SAToP Control Word...", forward-compatibility is gained. Assuming that
things might change and new needs might arise (future/different fields
or bitflags can , different sequencing, etc), a new CW can be defined
without the need of a completely new PW-Type. This future-compat allows
the use of alternate CWs on the same PW-Type for different needs.

Additionally, on the follow-up comment "The SAToP CW MUST be present in
the encapsulation, so there is no need to signal its presence during the
session establishment", draft-ietf-pwe3-tdm-control-protocol-extensi-00
includes this text for LDP:
	The Control bit MUST always be set for TDM PWs since all TDM PW
	encapsulations always use a control word.
and
	Note that setting of the Control bit (see section 2 above) to
	zero MUST result in an LDP status of "Illegal C-Bit".
so it would seem that the same should be followed by L2TPv3.

As for the Length Field usage, I believe that Scott Brim summarized it
very well in:
http://www1.ietf.org/mail-archive/web/pwe3/current/msg07456.html
For the advantage for direct mapping for interworking between MPLS and
L2TPv3 SAToP segments, only the fields that are relevant to the PW (and
not the transport) are of interest.

Regarding the VCCV discrimination field, I agree that's a characteristic
of the PW itself. However since VCCV payload uses different format for
MPLS and L2TPv3 in [VCCV], the advantage of this direct mapping dilutes
since interception and regeneration would be required.

Regards,

--Carlos.


Circa 9/29/2005 6:01 AM, Sasha Vainshtein said the following:
> 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
>>
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

-- 
--Carlos.
Escalation RTP - cisco Systems