Subject: [PWE3] PWE3 VCCV breakout meeting

From: Stewart Bryant <[email-masked]>
Date: Thu, 04 Aug 2005 06:58:36 +0100

These are the minutes of the PWE3 VCCV breakout meeting
that took place at lunch time yesterday.

[Note to PWE3 - these mins now contain the corrections
posted overnight]

There were a number of other issues that were raised
at these meeting that were out of scope. Those
issues should be raised on the PWE3 list.

- Stewart

VCCV over IP/RTP Breakout Mtg 3 Aug 2005 @ 1240
===============================================

Present:

Stewart Bryant (Chair)
Bill Stor
Luca martini
Maria Alice
Matthew Bocci
Ron Cohen
Sasha Vainshtein
Scot Wainner
Skip Booth (By Phone)
Tim Frost
Tom Nadeau
Yaakov Stein

Proposals on the Table at Start of Meeting
==========================================

- never include RTP in VCCV
- use ACH
- note that RTP header always starts with 8
etc

or

change order of headers

Discussion
==========

Issue of need to interconnect ip & mpls PWs

Two cases what to do with L2TP and what to do
with UDP/IP

Could change L2TPv3 encap, but UDP problem
remains.

Proposal fix L2TP to be like MPLS and leave
UDP and live with the problems.

UDP has no signalling and is unlikely to be
used for stitching/switching.

Note needs to be added to switching draft
to say that UDP switching to MPLS/L2TP
currently out of scope.

Need to relax the statement in VCCV saying that
sub-layer is REQUIRED.

Issue there is one implementation that uses
RTP then CW over L2TP. Needs backwards
compatibility mode.

Proposed Resolution for RTP and CW order for TDM PWs
====================================================

1) L2TP will use MPLS header ordering (i.e. L2TPv3/CW/RTP)
    MPLS CW will be used. i.e. pkt after the MPLS PW label
    and pkt after the L2TP session ident will be identical.

2) VCCV mux will use ACH (as specified in control word draft),
    and will NOT use RTP, even if the data stream used RTP.

3) Main text will describe use of MPLS order.

4) Informational Appendix describing old mode RTP/CW order
    in TDM drafts that are affected.

5) Need new option in RTP AVP for new (MPLS) order IN L2TP

6) Change to VCCV draft to describe the above

7) Need to update TDMoIP, CESoPSN, SATOP to reflect the
    above.

8) SONET draft not affected.

9 In UDP/IP PWs VCCV will not use RTP. In order for the
   VCCV selector ignore RTP pkts (and pass them to the
   TDM sub-system) - RTP header will be skipped by noting
   first nibble = 8.

Sasha noted that he needed to discuss the proposal with
his development team. Others present indicated support
for the proposal.

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

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Thu, 4 Aug 2005 04:23:19 -0700

Sasha,

One question inline.

alice

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sasha Vainshtein
> Sent: Thursday, 4 August, 2005 0:36
> To: Carlos Pignataro (cpignata)
> Cc: pwe3; Stewart Bryant (stbryant)
> Subject: RE: [PWE3] PWE3 VCCV breakout meeting
> 
> Carlos and all,
> Please see an Unfortunately, rather long) answer inline.
> I have snipped text that is not relevant to your proposal and 
> my answer to improve readability.
> 
> Regards,
>                           Sasha
> > -----Original Message-----
> > From: Carlos Pignataro [mailto:[email-masked]]
> > Sent: Wednesday, August 03, 2005 7:53 PM
> > To: Stewart Bryant
> > Cc: pwe3
> > Subject: Re: [PWE3] PWE3 VCCV breakout meeting
> > 
> > 
> > Please find one question inline (that may have already come up and 
> > been answered already).
> > 
> ,,, snipped ...
> > There were a number of other issues that were raised at 
> these meeting 
> > that were out of scope. Those issues should be raised on the PWE3 
> > list.
> ... snipped ...
> > > Two cases what to do with L2TP and what to do with UDP/IP
> > > 
> > > Could change L2TPv3 encap, but UDP problem remains.
> ... snipped ...
> > With this order, what is the benefit of hiding the CW presence (or 
> > L2-Specific Sublayer) from the control protocol L2TPv3?
> > It would seem that for TDM PWs over L2TPv3, defining a TDM-Specific 
> > Sublayer with the same sequencing format as the MPLS CW 
> would achieve 
> > the same results, but also:
> > o Would free 6 bits from the CW for L2TPv3, since the Length is not
> >   needed in l2tpv3.
> > o Would allow identifying and intercepting VCCV messages by 
> inspecting
> >   Bit 0 of the CW (the same way as described in VCCV draft for other
> >   L2TPv3 encaps) instead of the first nibble; this in turn:
> >   - Enables consistent vccv demux for L2TPv3 PWs
> >   - Frees up another 3 bits.
> >
> [Sasha]
> There are two reasons NOT to do that:
> 
> 1. VCCV as a common OAM mechanism for all kinds of PW 
> ============================================
> 
> We have been looking for a solution that would also allow 
> running VCCV over UDP/IP TDM PWs. The agreed upon resolution 
> has been based onan understaning that 3 types of packets can 
> be uniqquely identified by looking at the 1st nibble after 
> the demux (whatever it happens to be):
> 
> - Data packets that start with the CW will be identified by 
> carrying '0000' 
> 
> - Data packets that start with the RTP header will be 
> identified by carrying '1000' . 
>   (This covers RTP/UDP/IP packets since there are valid 
> technical considerations
>   (existing header compression techniques) for leaving this 
> order in place.
> This could
>   also cover RTP/L2TPv3/IP packets even without reversal of 
> the RTP/CW order
> 
>   - VCCV packets that will be identified by carrying '0001'.

If we restrict RTP hdr in RTP/L2TPv3/IP packets to have first
nibble as '1000', that means we can never have the P-bit and X-bit
turned on.  Is this ok?  Or should we say the first nibble should
be '10XX'?

alice

> 
> Of course, your proposal would break this as it would result 
> in VCCV packets carrying '1000' in the first nibble.
> 
> 2. Heterogenous PW Stitching
> ======================
> 
> The most important (IMHO) argument for reversing the RTP/CW 
> order was the need to make L2TPv3/MPLS PW stitching as 
> painless as possible in the data plane..
> 
> Ideally this should be restricted to:
> 
> - Popping the incoming PSN header (IP header or the tunnel 
> label stack)
> - Swapping the demultiplexers (Session ID and cookies <--> PW Label)
> - Pushing the outgoing PSN header (the tunnel label stack or 
> IP header)
> - Forwarding the resulting packet
> 
> The current proposal allows exactly this kind of stitching, 
> EVEN IF ONLY for TDM PWs.Your proposal would break this:
> 
> - The LEN field processing would be needed (this field IS 
> used in the MPLS-based
>   PW segments!)
> - FRG bits (used in one of the CESoPSN modes) would have to 
> be relocated etc.
> 
> Please note also that the BIG  "out of scope" issue raised at 
> the meeting was, of course, painless L2TPv3/MPLS stitching of 
> NON-TDM PWs.  
> 
> I shall present my considerations on this in a separate email 
> to the PWE3 and L2TPv3 WGs.
> 
> ... snipped ...
>

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Thu, 4 Aug 2005 04:33:29 -0700

Sasha,

The current l2tpv3 RFC supports signalling of the l2 sub-layer of
different types, default and non-default (i.e. ATM type).  So
we can do similar signalling for the SAToP CW.  All we need is to
define a l2 sub-layer type for SAToP CW in the l2tpext draft for
tdm.

alice

> Sent: Thursday, 4 August, 2005 2:34
> To: Scott Wainner (swainner); Carlos Pignataro (cpignata)
> Scott, Carlos and all,
> Please see a couple of brief comments inline below.
>  
> Regards,
>                           Sasha
> 
> 	From: Scott Wainner [mailto:[email-masked]]
> 	Sent: Wednesday, August 03, 2005 11:29 PM
> 	To: Carlos Pignataro
> 	Cc: pwe3; Stewart Bryant
> 	Carlos Pignataro wrote:
> 		Please find one question inline (that may have 
> already come up and been
> 		answered already).
> 		
> 		Circa 8/3/2005 9:02 AM, Stewart Bryant said the 
> following:
> 		  
> 
> 			that took place at lunch time today.
> 			
> 			Corrections from those present and 
> comments from the
> 			list on the proposed resolution are sought.
> 			
> 			Scot Weiner
> 			Need to fix statement in VCCV saying that
> 			sub-layer is REQUIRED.
> 			
> 	I don't think that was what is implied.  L2TPv3 control 
> protocol would have to specify that the
> 	MPLS CW would be used for consistency.
> 	[[Sasha]] IMHO this would require some additional 
> capabilities for L2TPv3. To the best of my recollection, 
> today you can only signal:
> 
> 	*	whether L2-specific sub-layer is present (so 
> that the L2TP switching machine would be aware of its 
> specific bits, e.g., S-bit)
> 	*	whether sequencing based on the L2-specific  
> sub-layer is enabled.
> 		
> 
> 		Sublayer with the same sequencing format as the 
> MPLS CW would achieve
> 		o Would allow identifying and intercepting VCCV 
> messages by inspecting
> 	I think the intent was for L2TPv3 to NOT do any 
> sequencing support for TDM.  In fact, the TDM
> 	sequencing would be a function handled by a highler 
> layer function.
> 	[[Sasha]] Absolutely. Sequencing for  TDM pseudo-wires 
> includes some highly specific features that are hardly part 
> of the generic L2TPv3.
> 
> 		While:
> 		o Would retain consistent sequencing space.
> 		o Would aware the control protocol of the 
> existence of a CW (or
> 		TDM-Specific Sublayer).
> 
> 	I still think we're talking about using the first bit 
> of an L2SS (V-bit) to identify the presence of a PW-AC or CW 
> for TDMoL2TPv3 ...  
> 	[[Sasha]] No, we are talking about always using 
> MPLS-compliant Associated Channel (marked with '0001' in the 
> first nibble). 
> 	
> 
> 		
> 		Thanks,
> 		
> 		--Carlos.
> 		
> 		  
> 
> 			2) VCCV mux will use ACH
> 			
> 			9 In UDP/IP PWs VCCV will not use RTP - 
> RTP header
> 			  will be skipped by noting first nibble = 8.
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 4 Aug 2005 15:45:23 +0300

Alice,
The SAToP and CESoPSN draft explicitly state that P and X bits in the RTP
header 
MUST be cleared.

I do not see it as a restriction since:
- RTP Padding functionality is not used
- eXtended RTP headers are not used either (the latter in explicit
conformance
  with RFC 2736.

Hope this clarifies the issue.

regards,
                  Sasha 

> From: Maria A. Dos Santos (mariados) [mailto:[email-masked]]
> Sent: Thursday, August 04, 2005 12:23 PM
> To: Sasha Vainshtein; Carlos Pignataro (cpignata)

---

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Thu, 4 Aug 2005 08:29:07 -0700

Sasha,

Thanx for the clarification.

alice =) 

> From: Sasha Vainshtein [mailto:[email-masked]] 
> Sent: Thursday, 4 August, 2005 5:45
> To: Maria A. Dos Santos (mariados); Carlos Pignataro (cpignata)
> The SAToP and CESoPSN draft explicitly state that P and X 
> bits in the RTP header MUST be cleared.
> 
> - eXtended RTP headers are not used either (the latter in 
> explicit conformance
>   with RFC 2736.
> 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Sasha Vainshtein
> > > I have snipped text that is not relevant to your proposal and my 
> > > answer to improve readability.
> > > 
> > > Regards,
> > >                           Sasha
> > > We have been looking for a solution that would also allow running 
> > > VCCV over UDP/IP TDM PWs. The agreed upon resolution has 
> been based 
> > > onan understaning that 3 types of packets can be uniqquely 
> > > identified by looking at the 1st nibble after the demux 
> (whatever it 
> > > happens to be):
> > > 
> > > - Data packets that start with the CW will be identified 
> by carrying 
> > > '0000'
> > > 
> > >   (This covers RTP/UDP/IP packets since there are valid technical 
> > > considerations
> > >   (existing header compression techniques) for leaving 
> this order in 
> > > place.
> > > This could
> > >   also cover RTP/L2TPv3/IP packets even without reversal of the 
> > > RTP/CW order
> > > 
> > If we restrict RTP hdr in RTP/L2TPv3/IP packets to have 
> first nibble 
> > as '1000', that means we can never have the P-bit and X-bit 
> turned on.  
> > Is this ok?  Or should we say the first nibble should be '10XX'?
> > 
> > alice
> > 
> > > 
> > > Of course, your proposal would break this as it would 
> result in VCCV 
> > > packets carrying '1000' in the first nibble.
> > > 
> > > The most important (IMHO) argument for reversing the RTP/CW order 
> > > was the need to make L2TPv3/MPLS PW stitching as painless as 
> > > possible in the data plane..
> > > 
> > > - Popping the incoming PSN header (IP header or the tunnel label 
> > > stack)
> > > - Pushing the outgoing PSN header (the tunnel label stack or IP 
> > > header)
> > > The current proposal allows exactly this kind of 
> stitching, EVEN IF 
> > > ONLY for TDM PWs.Your proposal would break this:
> > > 
> > > - The LEN field processing would be needed (this field IS used in 
> > > the MPLS-based
> > >   PW segments!)
> > > - FRG bits (used in one of the CESoPSN modes) would have to be 
> > > relocated etc.
> > > 
> > > Please note also that the BIG  "out of scope" issue raised at the 
> > > meeting was, of course, painless L2TPv3/MPLS stitching of NON-TDM 
> > > PWs.
> > > 
> > > I shall present my considerations on this in a separate 
> email to the 
> > > PWE3 and L2TPv3 WGs.
> > > 
> > > ... snipped ...
> > >