Re: [PWE3] VCCV usage

[Sriganesh Kini <[e-mail]>]

Carlos, that is useful clarification. If I were to summarize,

1. When a PW has a CW, CC Type 1 is obvious/implicit choice. However,
PW label TTL expiry should trigger examining the ACH for an VCCV
packet (both S-PE and T-PE).
2. When PW does not have CW, CC Type 3 should be used. When PWs were
single segment, the 'PW demultiplexer' TTL was defined as
application-specific (RFC 3985). With MS-PW it is important for it to
have consistent TTL decrement operations and treat TTL expiry (i.e.
TTL=1) packets as VCCV packets (both at S-PE and T-PE). This requires
the number of PW hops to be known to execute OAM targeted to a
particular S/T-PE and that is straightforward.

Note that TTL expiry VCCV is not inband when CW is not used since
intermediate nodes can look beyond the label stack and have different
ECMP behavior. A draft that addresses this condition by extending TTL
expiry VCCV was submitted at the last IETF
(draft-kini-pwe3-inband-cc-offset).

Thanks
-- 
- Sri


On Mon, Nov 29, 2010 at 7:45 AM, Carlos Pignataro (cpignata)
<[e-mail]> wrote:
> Sasha,
>
> Yes, like I said below you were referring to S5.1.3 of RFC 5085, which
> is discussing and applicable only to CC Type 3.
> Let me clarify what that section says:
>
> 5.1.3.  TTL Expiry VCCV (Type 3)
>
>   The TTL of the PW label can be set to 1 to force the packet to be
>   processed within the destination router's control plane.  This
>   approach could also result in a different ECMP hashing behavior and
>   VCCV messages taking a different path than the PW data traffic.
>
>   CC Type 3 can be used whether the PW is set-up with a Control Word
>   present or not.
>
> CP: This means the following: CC Type 3 can be used for PWs without a
> CW. CC Type 1 cannot. For a PW that does not have a CW, replacing the PW
> payload with an IPv4 packet containing a VCCV message can change the
> ECMP behavior. It's not the fact that the TTL is changed, it's the fact
> that what comes after the PW Label is changed, is not guaranteed to have
> started with 0x1 or 0x0, and now will likely start with 0x4.
>
>   If the Control Word is in use on this PW, it MUST also be included
>   before the VCCV message.  This is done to avoid the different ECMP
>   hashing behavior.  In this case, the CW uses the PW-ACH format
>   described in Section 5.1.1 (see Figures 3 and 4).  If the Control
>   Word is not in use on this PW, the VCCV message follows the PW Label
>   directly.
>
> CP: This means that for a PW that uses a CW, there is a design choice
> made which is that for a VCCV message, after the PW Label and before the
> actual VCCV message there is the PW-ACH. It's not needed as the
> interception is based on TTL and the packet is already at exception
> path, but it is desired to have the same ECMP behavior for data and OAM.
>
> Does that clarify?
>
> Thanks,
>
> -- Carlos.
>
> -----Original Message-----
> From: Alexander Vainshtein [mailto:[e-mail]]
> Sent: Monday, November 29, 2010 10:30 AM
> To: Carlos Pignataro (cpignata)
> Cc: Bocci, Matthew (Matthew); Yaakov Stein; Luca Martini (lmartini);
> [e-mail]; [e-mail]
> Subject: RE: [PWE3] VCCV usage
>
> Carlos,
> You've said that
>        There is no such assumption neither implicit nor explicit.
>        [[Sasha: that the same TTL is set in the PW label stack entry
> for data and VCCV packets that VCCV Type 1]],
>        VCCV Type 1 only assumes it can get to the target PE.
>
> I've made this assumption based on the following text in Section 5.1.3
> (VCCV Type 3) of RFC 5085:
>        The TTL of the PW label can be set to 1 to force the packet to
> be
>        processed within the destination router's control plane.  This
>        approach could also result in a different ECMP hashing behavior
> and
>        VCCV messages taking a different path than the PW data traffic.
>
> Section 5.1.1 (VCCV Type 1) does not contain any such caveats. And its
> header ("In-band VCCV") suggests that with this VCCV type, VCCV and data
> packets always follow the same pat thru the network.
>
> Since the only difference between the label stacks of VCCV and data
> packets in the case of VCCV Type 3 is the value of TTL in the PW label,
> this implies, IMO, that such a difference does not exist in the case of
> VCCV Type 1.
>
> This may be a bit far-fetched, of course. But it would be nice to
> clarify this point IMO.
>
> Regards,
>     Sasha
>
> -----Original Message-----
> From: Carlos Pignataro [mailto:[e-mail]]
> Sent: Monday, November 29, 2010 5:05 PM
> To: Alexander Vainshtein
> Cc: Bocci, Matthew (Matthew); Yaakov Stein; Martini; [e-mail];
> [e-mail]
> Subject: Re: [PWE3] VCCV usage
>
> Sasha,
>
> Sorry for the delayed response, please see inline.
>
> On 11/17/2010 12:47 AM, Alexander Vainshtein wrote:
>> Carlos, A couple of responses.
>>
>> 1. VCCV Type 2 does not work for MS-PWs, only for SS-PWs. Personally
>> I think that VCCV should be as agnostic as possible regarding
>> SS-PW/MS-PW differentiation, and hence VCCV Type 2 should be
>> deprecated.
>> 2. VCCV Type 1 assumes (or so I understand) that the same
>> TTL is set in the PW label stack entry for data and VCCV packets.
>
> There is no such assumption, neither implicit nor explicit. VCCV Type 1
> only assumes it can get to the target PE.
>
>> (At
>> least this is my reading of the text in RFC 5085 which hits that, due
>> to different appearance of the label stack in the data and VCCV Type
>> 3 packets, fate-sharing in VCCV Type 3 is not guaranteed, while such
>> fate-sharing is considered as guaranteed for VCCV Type 1).
>
> The only "TTL" mentions of RFC 5085 are within the VCCV Type 3 sections.
>  I think you are referring to Section 5.1.3 at
> <http://tools.ietf.org/html/rfc5085#section-5.1.3>, which only says that
> if there is a CW and using Type 3, then the CW is included taking the
> form of the PW-ACH.
>
>> Hence VCCV
>> Type 1 only provides a T-PE-to-T-PE communication channel (unless you
>> allow snooping of the first nibble of the CW in S-PEs, which to me is
>> a layer violation).
>
> I agree with this.
>
> Why then would S-PEs modify the T-PE's VCCV Type 1 capability
> potentially removing it?
>
>> 3. If a communication channel between a T-PE and
>> S-PE (or a pair of S-PEs) is required, ability to set TTL in the PW
>> label stack entry to a desired value on transmit is required. To me
>> this is a combination of VCCV Type 3 and VCCV Type 1.
>
> I agree with the first part, but this is VCCV Type 3 (as Type 1 is
> independent of the TTL). As you agreed that the VCCV Type means how we
> intercept the packet, setting the TTL to a specific value to expire at a
> given S-PE (sourced from S-PE or T-PE) is Type 3. This can happen with
> or without CW. Why would that be a combination?
>
> Thanks,
>
> -- Carlos.
>
>> I have already
>> described a use case where such a combination would be useful.
>>
>> Hopefully, these notes will be helpful.
>>
>> Regards, Sasha
>>
>>
>> ________________________________________ From: Carlos Pignataro
>> [[e-mail]] Sent: Tuesday, November 16, 2010 9:16 PM To:
>> Bocci, Matthew (Matthew) Cc: Alexander Vainshtein; Greg Mirsky;
>> Yaakov Stein; Luca Martini; Sriganesh Kini; [e-mail] 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 <[e-mail]
>>> <mailto:[e-mail]>> Date: Tue, 16 Nov 2010
>>> 18:20:04 +0100 To: Greg Mirsky <[e-mail]
>>> <mailto:[e-mail]>>, Yaakov Stein <[e-mail]
>>> <mailto:[e-mail]>>, Luca Martini <[e-mail]
>>> <mailto:[e-mail]>>, Sriganesh Kini
>>> <[e-mail] <mailto:[e-mail]>>
>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail]
>>> <mailto:[e-mail]>> 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:[e-mail]] *Sent:* Tuesday,
>>> November 16, 2010 2:57 PM *To:* Sriganesh Kini *Cc:* Alexander
>>> Vainshtein; [e-mail] <mailto:[e-mail]>; 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
>>> <[e-mail] <mailto:[e-mail]>>
>>> 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
>>> <[e-mail]
>>> <mailto:[e-mail]>> 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: [e-mail]
>>> <mailto:[e-mail]>[mailto:[e-mail]
>>> <mailto:[e-mail]>] On Behalf Of Sriganesh Kini
>>>> Sent: Tuesday, November 16, 2010 11:35 AM To: Yaakov Stein Cc:
>>>> [e-mail] <mailto:[e-mail]>; 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 <[e-mail]
>>> <mailto:[e-mail]>> 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 [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>>
>>>> _______________________________________________ pwe3 mailing list
>>>>  [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>> _______________________________________________ pwe3 mailing list
>>>>  [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>>
>>> -- - Sri
>>>
>>> _______________________________________________ pwe3 mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>
>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________ pwe3 mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/pwe3
>> _______________________________________________ pwe3 mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/pwe3
>>
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>