Subject: RE: [PWE3] PWE3 VCCV breakout meeting

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

Carlos,
Please see some answers inline.

Regards,
                           Sasha

> -----Original Message-----
> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: Thursday, August 04, 2005 1:56 PM
> To: Sasha Vainshtein
> Cc: pwe3; Stewart Bryant
> Subject: Re: [PWE3] PWE3 VCCV breakout meeting
> 
> 
> Sasha,
> 
> Thank you for your prompt answer. Please see inline some 
> follow up comments.
> 
> Circa 8/4/2005 3:36 AM, Sasha Vainshtein said the following:
> > 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 ...
> > 
> >>>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?
> >>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):
> > 
> 
> How does this fit with the minutes discussion that "Proposal 
> fix L2TP to be like MPLS and leave UDP and live with the problems." and 
> "UDP has no  signalling and is unlikely to be used for
stitching/switching."? 
[Sasha] This means that UDP/MPLS PW stitching has been left out of scope,
while VCCV over UDP has been taken care of.
>
> I was also under the assumption that "TDMoIP has always had,  and still
has,
> its own OAM mechanism, which is similar to VCCV and runs over 
> UDP." from an earlier email in the list.
>
[Sasha]  I'd rather ask Yaakov to address that. But, to the best of my
recollection,
TDMoIP-specific OAM has NOT been discussed during the meeting.
>
> > - 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'.
> > 
> > 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:
> > 
> 
> No, it wouldn't break these. I guess what I'm asking is why 
> have fields
> that are not applicable to the encapsulation? Please note that the
> format agreed on would also be used in the non-stitching case. What's
> the meaning of the Length field in TDMoL2TPv3?
> 
[Sasha] I read this as two different issues:

1. You claim that non-usage of the LEN field in L2TPv3-based encapsulations
does not
    break the painless stitching mechanism between L2TPv3 and MPLS PWs.
    I disagree: 
    - MPLS PWs need this field to distingush bweteen the original payload
and
      padding of short packets
    - If this field was not present in the L2TPv3 encapsulation, the only
way to reconstruct
      it for the switching would be to re-calcualte it based on the Length
field in the IP header.
    - This is quite a bit of processing to add to the painless scheme (IMO).

2. What should we optimise the encapsulation for: the non-stitching case or
the stitching one?
    Given that the drive behind the reversal proposal has been driven by the
stitching case,
    I'd say "if you do any changes at all,then optimize for the stitching
case all the way" 
    (otherwise we could leave the originally proposed RTP/CW header order in
place ).
  
> 
> > - The LEN field processing would be needed (this field IS 
> used in the
> > MPLS-based 
> >   PW segments!)
> 
> Sure, but only in the MPLS segment.
>
[Sasha] Please see above.
> 
> > - FRG bits (used in one of the CESoPSN modes) would have to 
> be relocated
> > etc.
> 
> Why relocated? The CW for L2TPv3 could have the exact same 
> format as the
> MPLS one, with the exception of freeing up the Len field and bits 1-3;
> that is using bit 0 as the VCCV indicator, as the other L2TPv3
> encapsulations.
> 
> Regards,
> 
> --Carlos.
> 
> > 
> > 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 ...
> > 
> 
> -- 
> --Carlos.
> Escalation RTP - cisco Systems
> 

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

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 04 Aug 2005 10:48:09 -0400

Sasha,

I believe we're almost on the same page with regards to optimizing the
stitching case; it appears to me that this optimization primarily means
CW/RTP ordering and location of common fields in the CW. However, I do
not see the need to penalize an L2TPv3 segment or single segment PW with
the addition of the Length not used.
The other pending item is whether there is any benefit in hiding the CW
presence from L2TPv3, or as it was suggested define a TDM-Specific
Sublayer (i.e. non-default) and use similar signal in TDMoL2TPv3.

Regards,

--Carlos.