Subject: RE: [PWE3] PWE3 VCCV breakout meeting

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

Carlos,
Again (I believe I have said that already), the current proposal
is driven not only by the data/VCCV demux considerations (in spite
the header) but also (and, IMHO, primarily) by the L2TPv3/MPLS PW
stitching/splicing considerations.

And these considerations force upon you maximal conformance between the
CWs (and anything else) in the two encapsulations (preferably they should 
be exactly the same).

Regards,
                    Sasha

> -----Original Message-----
> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Thursday, August 04, 2005 1:34 PM
> To: Sasha Vainshtein
> Cc: 'Scott Wainner'; pwe3; Stewart Bryant
> Subject: Re: [PWE3] PWE3 VCCV breakout meeting
> 
> 
> Sasha,
> 
> Please find two quick comments inline.
> 
> Circa 8/4/2005 5:33 AM, Sasha Vainshtein said the following:
> > Scott, Carlos and all,
> > Please see a couple of brief comments inline below.
> >  
> > Regards,
> >                           Sasha
> > 
> >     -----Original Message-----
> >     *From:* Scott Wainner [mailto:[email-masked]]
> >     *Sent:* Wednesday, August 03, 2005 11:29 PM
> >     *To:* Carlos Pignataro
> >     *Cc:* pwe3; Stewart Bryant
> >     *Subject:* Re: [PWE3] PWE3 VCCV breakout meeting
> > 
> > 
> > 
> >     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:
> >>  
> >>
> >>>These are the minutes of the PWE3 VCCV breakout meeting
> >>>that took place at lunch time today.
> >>>
> >>>Corrections from those present and comments from the
> >>>list on the proposed resolution are sought.
> >>>
> >>>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 Weiner
> >>>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 fix 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)
> >>>    
> >>
> >>
> >>With this order, what is the benefit of hiding the CW presence (or
> >>L2-Specific Sublayer) from the control protocol L2TPv3?
> > 
> >     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.
> > 
> >>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.
> > 
> >     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). 
> 
> That's what I was wondering. Why use an MPLS-compliant CW for L2TPv3,
> since 2 fields of the CW are not applicable to L2TPv3 (i.e. Length and
> "ECMP-avoidance discriminator")? Instead, TDMoL2TPv3 can include its
> specific sequencing features/requirements in a TDM-Specific Sublayer
> signaled using L2TPv3 control protocol. What would be the advantage of
> not doing so and hiding the CW from L2TPv3?
> 
> Regards,
> 
> --Carlos.
> 
> > 
> >>Thanks,
> >>
> >>--Carlos.
> >>
> >>  
> >>
> >>>2) VCCV mux will use ACH
> >>>
> >>>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 - 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
> >>>
> >>>    
> >>
> >>
> >>  
> 
> -- 
> --Carlos.
> Escalation RTP - cisco Systems
> 

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

---

From: Scott W Brim <[email-masked]>
Date: Thu, 04 Aug 2005 17:26:40 +0200

> CWs (and anything else) in the two encapsulations (preferably they should 

Some header information is specific to the transport protocol, e.g.
length.  Other information is relevant to the PW.  As long as you have
a clear mapping of the semantic information between each side for the
second type, you're okay.