Re: [PWE3] VCCV usage

Dear Sri,
I think it is quite clear that if CW is enabled on a PW and TTL is not
expired, regardless whether Type 3 CC enabled or not, ACH VCCV packets must
be sent to the control plane and payload (packets with CW) must be sent to
Native Service for processing without the CW. Thus no OAM packets will be
leaked off PW.

Regards,
Greg

On Tue, Nov 16, 2010 at 1:55 PM, Sriganesh Kini <sriganesh.kini@ericsson.com
> wrote:

> Hi Mustapha,
>
> Note that even when TTL does not expire, the first nibble of the CW must
> being 0000 for it to be processed as a data plane packet (In fact there are
> other fields in the CW beyond the first nibble that need handling as well).
> I agree that the interpretation of RFC5085 is not entirely clear when Type-3
> is used with CW and TTL does not expire at egress T-PE for a VCCV packet.
> However under no condition should that result in the VCCV packet being
> forwarded on the AC since the first nibble would be 0001 and that is not a
> data packet. However this whole condition of TTL not expiring with Type 3 is
> somewhat theoritical, since as Luca pointed out determining the number of
> hops is rather straightforward.
>
>
> - Sri
> ________________________________
> From: Aissaoui, Mustapha (Mustapha) [mustapha.aissaoui@alcatel-lucent.com]
> Sent: Tuesday, November 16, 2010 11:42 AM
> To: Sriganesh Kini; Bocci, Matthew (Matthew)
> Cc: pwe3@ietf.org; Luca Martini; Yaakov Stein
> Subject: RE: [PWE3] VCCV usage
>
> Sri,
> When CC Type 3 is negotiated, the egress T-PE data path exception handling
> will rely solely on the TTL expiry to re-direct a packet to the control
> plane for further processing. If TTL expires, then the control plane can
> recognize the OAM CW and remove it and continue further processing of the
> VCCV packet.
>
> If however the TTL does not expire, the VCCV packet is treated like a data
> plane packet and the OAM CW gets removed and the rest of the packet gets
> forwarded to the AC. That is the issue with CC Type 3 in a MS-PW.
>
> Mustapha.
>
> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Sriganesh Kini
> Sent: Tuesday, November 16, 2010 1:37 PM
> To: Bocci, Matthew (Matthew)
> Cc: pwe3@ietf.org; Luca Martini; Yaakov Stein
> Subject: Re: [PWE3] VCCV usage
>
> Matthew,
>
> When PW is setup with CW, the egress T-PE always examines the CW for
> further processing. This is true for even data packets and is independent of
> which CC Type is negotiated. Even if Type 3 was negotiated and independent
> of whether TTL did or did not expire, there shouldn't be any reason for VCCV
> not to be processed if the first nibble of CW indicates that.
>
> On Tue, Nov 16, 2010 at 9:46 AM, Bocci, Matthew (Matthew) <
> matthew.bocci@alcatel-lucent.com> wrote:
> > Hi Sasha,
> > Please see below.
> > Matthew
> > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> > Date: Tue, 16 Nov 2010 18:20:04 +0100
> > To: Greg Mirsky <gregimirsky@gmail.com>, Yaakov Stein
> > <yaakov_s@rad.com>, Luca Martini <lmartini@cisco.com>, Sriganesh Kini
> > <sriganesh.kini@ericsson.com>
> > Cc: "pwe3@ietf.org" <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 1st
> > 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
> > MB> 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; 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> 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> 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] On Behalf
> >> Of Sriganesh Kini
> >> Sent: Tuesday, November 16, 2010 11:35 AM
> >> To: Yaakov Stein
> >> Cc: 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> 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
> >>> 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
> >>
> >
> >
> > --
> > - Sri
> >
> > _______________________________________________
> > 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
> >
> >
>
>
>
> --
> - Sri
> _______________________________________________
> 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
>