Re: [PWE3] VCCV usage

Mustapha, Matthew,

Thanks for the quick reply. Therefore, if there is no "snooping" of the
CW, there is no CC Type 1. That is, no such a thing as CC Type 1 at the
S-PE, and that should not be advertised. Correct?
Any thoughts on the other questions regarding CC Type 2 and combination
of CC Types?

Thanks,

-- Carlos.

-----Original Message-----
From: Aissaoui, Mustapha (Mustapha)
[mailto:mustapha.aissaoui@alcatel-lucent.com] 
Sent: Tuesday, November 16, 2010 2:48 PM
To: Carlos Pignataro (cpignata); Bocci, Matthew (Matthew)
Cc: Luca Martini (lmartini); Yaakov Stein; pwe3@ietf.org
Subject: RE: [PWE3] VCCV usage

Carlos,
You are correct, the CC Types are signaled such that each PE knows the
capability of its peer in terms of interception of OAM packets in the
data path, i.e., the exception handling procedures.

The control plane can always recognize an OAM control word and remove it
when processing the VCCV packet but the data path must first intercept
it and re-direct it to the control plane.

Mustapha. 

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
Carlos Pignataro
Sent: Tuesday, November 16, 2010 2:17 PM
To: Bocci, Matthew (Matthew)
Cc: Luca Martini; Yaakov Stein; pwe3@ietf.org
Subject: Re: [PWE3] VCCV usage

Sasha, Matthew, all,

Please find a couple of top-post questions for my understanding of the
thread:

1. When we say "CC Type", what is the definition used and semantics?
   From S3 of RFC5085 <http://tools.ietf.org/html/rfc5085#section-3>, I
   believe this thread is about the second bullet, that includes "allows
   the receiving PE to intercept [...]". Therefore:

   a. From there, if TTL expires, then that would mean that CC Type 3 is
      being used (regardless of CW 1st nibble, since CC Type 3 for PWs
      that use CW need to set the nibble to 0x1 but does they not use it
      for intercepting, per S5.1.3 of RFC 5085). Right?

   b. If OTOH the 1st nibble is inspected and intercepted when 0x1
      regardless of TTL, then that's CC Type 1. Correct?

2. What are the reasons for deprecating CC Type 2, as for intercepting
   it works every time.

3. What does it mean to combine CC Type 1 and CC Type 3? I think that
   the distinction is semantically in regards to how the VCCV packets
   are intercepted from the PW dataplane stream. The fact that CC Type 3
   uses the CW with 0x1 and PW-ACH is not for intercepting, but for OAM
   fate-sharing, per <http://tools.ietf.org/html/rfc5085#section-5.1.3>.

4. All of these thread covers the dataplane aspect and not the
   capability signaling, correct?

Thanks,

-- Carlos.

On 11/16/2010 12:46 PM, Bocci, Matthew (Matthew) wrote:
> Hi Sasha,
> 
> Please see below.
> 
> Matthew
> 
> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com 
> <mailto:Alexander.Vainshtein@ecitele.com>>
> Date: Tue, 16 Nov 2010 18:20:04 +0100
> To: Greg Mirsky <gregimirsky@gmail.com 
> <mailto:gregimirsky@gmail.com>>, Yaakov Stein <yaakov_s@rad.com 
> <mailto:yaakov_s@rad.com>>, Luca Martini <lmartini@cisco.com 
> <mailto:lmartini@cisco.com>>, Sriganesh Kini 
> <sriganesh.kini@ericsson.com <mailto:sriganesh.kini@ericsson.com>>
> Cc: "pwe3@ietf.org <mailto:pwe3@ietf.org>" <pwe3@ietf.org 
> <mailto:pwe3@ietf.org>>
> Subject: Re: [PWE3] VCCV usage
> 
> Hi all,
> 
> It seems that we have moved far, far away from the original topic of 
> this discussion, namely, which VCCV types should be deprecated 
> andwhich declared as /mandatory to implement/. (I would like to stress

> the difference  between /mandatory to implement/ and /mandatory to 
> deploy/; the latter is IMO out of  scope of this discussion).
> 
>  
> 
> I would like to summarize my understanding of the discussion on this 
> specific topic.
> 
>  
> 
> 1.       It seems that we more or less agree that VCCV Type 2 should
be
> deprecated. If we accept this, an update to RFC 5085 (that defines 
> that, when multiple VCCV Types are supported, it is preferable to VCCV

> Type 3) has to be amended.
> 
> 2.       It also seems that VCCV Type 3 goes almost for free: all that
> is required is /ability to send  VCCV packets with the desired TTL 
> value in the PW label stack entry/ (as opposed to always setting TTL 
> in this stack entry to a fixed value).
> 
> 3.       We disagree on whether VCCV Type 3 is absolutely required for
> terminating some VCCV packets in S-PEs, with snooping on the 1^st 
> nibble of the CW as an alternative.  But we seem to agree  that TTL 
> expiration is a standard-compliant approachhere.
> 
> 
> MB> Actually we should never snoop the first nibble unless TTL expires
> at an S-PE. This is common for both S-PEs that advertise Type 1 and 
> Type 3, and draft-ietf-pwe3-segmented-pw is pretty clear about this
point.
> The difference is the behaviour at the T-PE. With type 1, the first 
> nibble of the CW is always inspected when the PW label is popped. With

> type 3, TTL must expire for the CW (if present) to be inspected.
> 
> It is interesting to note that this is the second time we have been 
> through the same line of thought on this list (see the following 
> thread from These differences were discussed in the following thread
on the
> PWE3 list   from July this
> year: http://www.ietf.org/mail-archive/web/pwe3/current/msg11466.html)
> 
> 
> 4.       Combining VCCV Type 1 and Type 3:
> 
> a.       We all seem to agree that VCCV Type 1 (where applicable)
> provides protection against leaking VCCV packets in ACs
> 
> b.      RFC 5086 states that in PWs using the CW, the PW-ACH header
> (i.e., the CW with the first nibble set to 0b0001 and the last 16 bits

> carrying the ACH Type) MUST be used even with VCCV Type 3. In other 
> words, a device that supports usage of CW in PWs and supports VCCV 
> Type
> 3 MUST be able to DEMUX VCCV packets that it has identified due to TTL

> expiration in the PW label stack entry MUST be on ACH type.  However, 
> it could be useful to clarify this point explicitly when/if we amend
RFC 5086.
> 
> c.       This observation (assuming it is acceptable) covers the use
> cases for combining VCCV Type 1 and VCCV Type 3 that I have in mind.
> 
>  
> 
> Hopefully these notes will be useful.
> 
> Regards,
> 
>      Sasha
> 
>  
> 
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Tuesday, November 16, 2010 2:57 PM
> *To:* Sriganesh Kini
> *Cc:* Alexander Vainshtein; pwe3@ietf.org <mailto:pwe3@ietf.org>; 
> Yaakov Stein; Luca Martini
> *Subject:* Re: [PWE3] VCCV usage
> 
>  
> 
> Dear Sri,
> 
> I think that is interesting question whether Segment protection is 
> applicable to MS-PW. I cannot say that such requirement doesn't exist 
> only because protection on different sub-layers must be coordinated.
> 
>  
> 
> Regards,
> 
> Greg
> 
> On Tue, Nov 16, 2010 at 2:07 AM, Sriganesh Kini 
> <sriganesh.kini@ericsson.com <mailto:sriganesh.kini@ericsson.com>>
wrote:
> 
> IMO mid-point protection is not required. Your proposal has 
> complications because a sub-segment of that segment may also be 
> monitoring and independently do a protection-switched resulting in the

> number of hops changing for the segment.
> 
> 
> On Tue, Nov 16, 2010 at 1:37 AM, Alexander Vainshtein 
> <Alexander.Vainshtein@ecitele.com 
> <mailto:Alexander.Vainshtein@ecitele.com>> wrote:
>> Yaakov, Sri,
>> I am not sure if mid-point protection switch is really useful.
>> But if it is, can it be triggered by segment monitoring using VCCV
Type 3?
>> This would eliminate the need for permanent snooping on the CW.
>>
>> Regards,
>>     Sasha
>>
>> -----Original Message-----
>> From: pwe3-bounces@ietf.org
> <mailto:pwe3-bounces@ietf.org>[mailto:pwe3-bounces@ietf.org
> <mailto:pwe3-bounces@ietf.org>] On Behalf Of Sriganesh Kini
>> Sent: Tuesday, November 16, 2010 11:35 AM
>> To: Yaakov Stein
>> Cc: pwe3@ietf.org <mailto:pwe3@ietf.org>; Luca Martini
>> Subject: Re: [PWE3] VCCV usage
>>
>> I agree with Luca. Peeking at the first nibble at S-PEs for every 
>> packet, warps the label swap operation at S-PEs. It is best to stick 
>> to the standard MPLS label operations.
>>
>> Moreover, would initiating midpoint-backup require initiating the 
>> VCCV-BFD from that mid-point ? Would that potentially terminate at 
>> another midpoint ? This would result in all intermediate S-PEs 
>> examining the VCCV packets beyond the first nibble to determine if it

>> is destined to it, and if not would require forwarding (that may not 
>> be in data plane). This introduces unnecessary delays of BFD packets.
>>
>> --
>> - Sri
>>
>> On Mon, Nov 15, 2010 at 9:11 PM, Yaakov Stein <yaakov_s@rad.com
> <mailto:yaakov_s@rad.com>> wrote:
>>>> Your concern is one of the main reasons why S-PEs cannot support 
>>>> midpoint-backup-PWs.
>>>
>>> Luca
>>>
>>> Actually, my concern is one of the reasons that they can.
>>>
>>> All you have to do is set up the backup MS-PW, and trigger the 
>>> switch based on VCCV-BFD indications.
>>>
>>> Works like a charm, if you allow the S-PEs to peek at the first
nibble.
>>>
>>> BTW, not ALL the S-PEs need to know. Only the S-PEs affected by the
> backup.
>>> But all of this depends on NOT using the TTL-expiry method, which is

>>> clumsy at best, and error-prone at worst.
>>>
>>> Y(J)S
>>>
>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> pwe3@ietf.org <mailto:pwe3@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>
>> _______________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org <mailto:pwe3@ietf.org>
>> https://www.ietf.org/mailman/listinfo/pwe3
>> _______________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org <mailto:pwe3@ietf.org>
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
> 
> 
> --
> - Sri
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org <mailto:pwe3@ietf.org>
> https://www.ietf.org/mailman/listinfo/pwe3
> 
>  
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3