Subject: RE: [PWE3] PWE3 VCCV breakout meeting

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 4 Aug 2005 10:36:06 +0300

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):

- 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:

- 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 ...

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

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 04 Aug 2005 08:55:55 -0400

Sasha,

Thank you for your prompt answer. Please see inline some follow up comments.

> 1. VCCV as a common OAM mechanism for all kinds of PW

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."? 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.

> 2. Heterogenous PW Stitching

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?

> - The LEN field processing would be needed (this field IS used in the

Sure, but only in the MPLS segment.

> - FRG bits (used in one of the CESoPSN modes) would have to be relocated

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.

-- 
--Carlos.
Escalation RTP - cisco Systems