Subject: [PWE3] VCCV usage

From: Yaakov Stein <[email-masked]>
Date: Thu, 11 Nov 2010 08:42:17 +0000

Nick and all,

I would like to follow through on my suggestion at the mike.

I think the most reasonable VCCV usage should be as follows:

1)   For encaps that mandate CW use, type 1 (CW) MUST be used.

2)   For other encaps, if CW is being used, then type 1 SHOULD be used,

and types 2 (router alert label) or 3 (TTL expiry) MAY be used.

3)   For other encaps when not using the CW, type 3 MUST be supported, and 2 MAY be used.

This reduces interop issues going forward, while not breaking existing implementations without CWs.

Y(J)S

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 11 Nov 2010 11:28:49 +0200

Yaakov and all,

IMO when it comes to VCCV we should look for a disposition that would suit the needs of both single-segment and multi-segment PWs.

VCCV Type 3 is the only technique that can support segment-related OAM for multi-segment PWs. This is explained in detail in the Segmented PWs<http://datatracker.ietf.org/doc/draft-ietf-pwe3-segmented-pw/?include_text=1> draft (now in the RFC Editor queue) with many examples, and it is not affected by presence or absence of the CW in encapsulation because S-PEs do not examine the CW. The same document  also precludes usage of VCCV Type 2 for multi-segment PWs.

When it comes to end-to-end (i.e., T-PE to T-PE) VCCV for MS-PWs, the only problem with VCCV Type 3 is the possibility of leaking a VCCV packet out of the PW if its TTL has not been set correctly by the transmitter. Hence the need to use VCCV Type 1 where possible.

And of course, VCCV Type 1 offers additional level of demuxing on Channel Type.

Based on that, I'd say that we should:

*         Actively discourage usage of VCCV Type 2 as not compatible with MS-PWs

*         Promote a combination of VCCV Type 3 and, where applicable,  VCCV Type 1 as an approach that meets the needs of both single-segment and multi-segment PWs.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Thursday, November 11, 2010 10:42 AM
To: [email-masked]
Subject: [PWE3] VCCV usage

Nick and all,

Y(J)S

---

From: Sri <[email-masked]>
Date: Fri, 12 Nov 2010 02:34:55 -0800

It is important to have TTL Expiry VCCV (Type 3) . IMO, leaking should
not be a concern as the number of hops should not change dynamically.
If it is still a concern it can be used with CW.

Another important consideration is for VCCV to be inband even for
multipath. This must be independent of whether CW is used.

-- 
Sri

On Thu, Nov 11, 2010 at 1:28 AM, Alexander Vainshtein
<[email-masked]> wrote:
> Yaakov and all,
>
>
>
> IMO when it comes to VCCV we should look for a disposition that would suit
> the needs of both single-segment and multi-segment PWs.
>
>
>
> VCCV Type 3 is the only technique that can support segment-related OAM for
> multi-segment PWs. This is explained in detail in the Segmented PWs draft
> (now in the RFC Editor queue) with many examples, and it is not affected by
> presence or absence of the CW in encapsulation because S-PEs do not examine
> the CW. The same document  also precludes usage of VCCV Type 2 for
> multi-segment PWs.
>
>
>
> When it comes to end-to-end (i.e., T-PE to T-PE) VCCV for MS-PWs, the only
> problem with VCCV Type 3 is the possibility of leaking a VCCV packet out of
> the PW if its TTL has not been set correctly by the transmitter. Hence the
> need to use VCCV Type 1 where possible.
>
>
>
> Based on that, I’d say that we should:
>
> ·         Actively discourage usage of VCCV Type 2 as not compatible with
> MS-PWs
>
> ·         Promote a combination of VCCV Type 3 and, where applicable,  VCCV
> Type 1 as an approach that meets the needs of both single-segment and
> multi-segment PWs.
>
>
>
> Regards,
>
>      Sasha
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 12 Nov 2010 12:08:38 +0000

Sasha

OK, so we agree as to the wisdom of deprecating Type 2.   So far so good.

As to your other argument, it sounds like a side issue.
The number of MS-PWs is insignificant as compared to the number of single segment ones.
Some small fraction of the former will need segmental OAM.
Burdening the large base of PWs for this negligible number of cases sounds a lot like
requiring all routers to support of some archane IP option.

In any case, I am OK with several possible variants of my suggestion to enable MS-PW behavior.
Will you allow me to assume that the ingress PE knows that it is injecting into a multisegment PW ?

Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, November 11, 2010 11:29
To: Yaakov Stein
Cc: [email-masked]
Subject: RE: VCCV usage

Yaakov and all,

Regards,
     Sasha

Nick and all,

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 12 Nov 2010 12:11:59 +0000

I agree with Sasha that we need to protect against the number of hops changing,
when the PW is placed in a tunnel set up by LDP.

However, that is one of the reasons I don't like TTL expiry.
It requires too much configuration, or alternatively a TTL discovery mechanism.

Y(J)S

-----Original Message-----
From: Sri [mailto:[email-masked]] 
Sent: Friday, November 12, 2010 12:35
To: Alexander Vainshtein
Cc: Yaakov Stein; [email-masked]
Subject: Re: [PWE3] VCCV usage

-- 
Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 12 Nov 2010 13:26:34 -0800

Yaakov,

The tunnel setup protocol should not matter since the TTL expiry VCCV
depends on the PW label TTL. When the PW is placed in a tunnel setup
by LDP and the number of hops of the LDP tunnel change, the same PW
label TTL must be used for VCCV.

- Sri

-- 
Sriganesh Kini (Sri)

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Sat, 13 Nov 2010 01:16:08 +0100

Sri,

Still, you are relying on the TTL to be set correctly by the sending
T/S-PE to prevent a fairly significant issue at the receiving T-PE. TTL
expiry only ensures that a VCCV packet will be intercepted at a T-PE
rather then being forwarded on the AC if TTL is set correctly. Type 1
ensures that this does not happen because the 1st four bits of the control
word are always checked when the PW label is popped.

Matthew

On 12/11/2010 21:26, "Sriganesh Kini" <[email-masked]> wrote:

>>> And of course, VCCV Type 1 offers additional level of demuxing on
>>>Channel
>>> Type.
>>>
>>>
>>>
>>> Based on that, I¹d say that we should:
>>>
>>> 3)   For other encaps when not using the CW, type 3 MUST be supported,
>>>and 2
>>> MAY be used.
>>>
>>>
>>>

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 12 Nov 2010 16:48:43 -0800

Matthew,

Type-3 can also be used in MS-PW. Type-3 can be used with CW enabled
in situations where there is concern of PW label TTL not being set
correctly at ingress.

-- 
- Sri

---

From: Yaakov Stein <[email-masked]>
Date: Sat, 13 Nov 2010 17:32:16 +0000

Sri,

Almost.

In theory a failure may cause a simple PW to be backed up by a MS one,
thus changing the number of PW hops.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Friday, November 12, 2010 23:27
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [PWE3] VCCV usage

Yaakov,

- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Sun, 14 Nov 2010 00:07:52 -0800

Hi Yaakov,

Each of the SS-PW and the (backup) MS-PW should have their own TTL and
VCCV. The number of PW hops should not change for either of the PWs.

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 14 Nov 2010 08:17:31 +0000

Sri

I hear that you are saying that it should not change.

I already agreed that this is the typical case, 
but as I said I am not sure that it is the only case.

Let me explain in more detail what I mentioned in my previous email.
Consider a SP that has several MPLS networks, each of which is separate at the MPLS layer,
but across any combination of which you can set up PWs.
Now take, for example, a PW that is initially set up as a SS one.
Due to a failure the PW can only be maintained by going outside the original MPLS network
to a transit network, and then back in. 
So from a single segment PW it becomes a 3-segment PW.  PW-label TTL changes.

Furthermore, as I asked Sasha, the ingress PE does not know if it is SS,
or if MS how many segments there are.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Sunday, November 14, 2010 10:08
To: Yaakov Stein
Cc: Sriganesh Kini; [email-masked]
Subject: Re: [PWE3] VCCV usage

Hi Yaakov,

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 14 Nov 2010 13:57:56 +0200

Yaakov, Sri and all,
I am not sure why going to a different MPLS network in Yaakov's example would result in replacing a single-segment PW with a multi-segment one. IMO protection would probably happen at the tunnel level, not at the PW level.
And in any case, the ingress PE would be aware of the change because the PW label it transmits would change (it has been allocated by the remote T-PE before the switch, but after the switch it is allocated by the nearest S-PE).

I would further notice that as long as we are dealing with SS-PWs (which indeed represent most of the current PW deployments), VCCV Type 3 using TTL = 1 in the PW label entry looks safe enough (I do not think we should worry about non-standard equipment that does not check TTL in the label stack entries). It is only MS-PWs that are potentially problematic when it comes to leaking VCCV packets to ACs. Hence I would like us to be internally consistent among themselves: either we do not care about MS-PWs - and hence VCCV Type 3 is sufficient, or we want to cover MS-PWs - and then segment VCCV is important. One use case that comes to mind is propagation of PW status across a MS-PW comprised of both static and dynamically signaled segments.

As for original Yaakov's question - whether the ingress PE "knows" with which case it deals, and in the case of a MS-PW, how many segments there are: IMO this is a very important question indeed. One way to answer it would be IMO by defining MS-PW extensions to the PW MIB. According to the WG Charter this was supposed to be ready in July 2009, but I have not found any signs of related activity.
Another answer (actually suggested by Yaakov) would be to use trace route for MS-PWs as described in the Segmented PWs draft.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Sunday, November 14, 2010 10:18 AM
To: Sriganesh Kini
Cc: [email-masked]
Subject: Re: [PWE3] VCCV usage

Sri

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Sunday, November 14, 2010 10:08
To: Yaakov Stein
Cc: Sriganesh Kini; [email-masked]
Subject: Re: [PWE3] VCCV usage

Hi Yaakov,

---

From: Sri <[email-masked]>
Date: Sun, 14 Nov 2010 16:14:37 -0800

Hi Sasha,

I agree that in many cases the protection will happen at the tunnel
level. Even for the case that Yaakov described, when the (backup)
MS-PW is setup, the number of hops should be independently determined.
Even though a client may view the (primary) SS-PW and the (backup)
MS-PW as a single logical entity, they have distinct VCCV.

Only MS-PW without CW has a theoretical possibility of leaking VCCV. A
hop count determination method (I prefer path trace) should eliminate
that. It should be recommended that all PWs (SS/MS) use that method in
order to keep the procedures at  T-PE independent of SS/MS.

Thanks

On 11/14/10, Alexander Vainshtein <[email-masked]> wrote:
> Yaakov, Sri and all,
> I am not sure why going to a different MPLS network in Yaakov's example
> would result in replacing a single-segment PW with a multi-segment one. IMO
> protection would probably happen at the tunnel level, not at the PW level.
> And in any case, the ingress PE would be aware of the change because the PW
> label it transmits would change (it has been allocated by the remote T-PE
> before the switch, but after the switch it is allocated by the nearest
> S-PE).
>
> I would further notice that as long as we are dealing with SS-PWs (which
> indeed represent most of the current PW deployments), VCCV Type 3 using TTL
> = 1 in the PW label entry looks safe enough (I do not think we should worry
> about non-standard equipment that does not check TTL in the label stack
> entries). It is only MS-PWs that are potentially problematic when it comes
> to leaking VCCV packets to ACs. Hence I would like us to be internally
> consistent among themselves: either we do not care about MS-PWs - and hence
> VCCV Type 3 is sufficient, or we want to cover MS-PWs - and then segment
> VCCV is important. One use case that comes to mind is propagation of PW
> status across a MS-PW comprised of both static and dynamically signaled
> segments.
>
> As for original Yaakov's question - whether the ingress PE "knows" with
> which case it deals, and in the case of a MS-PW, how many segments there
> are: IMO this is a very important question indeed. One way to answer it
> would be IMO by defining MS-PW extensions to the PW MIB. According to the WG
> Charter this was supposed to be ready in July 2009, but I have not found any
> signs of related activity.
> Another answer (actually suggested by Yaakov) would be to use trace route
> for MS-PWs as described in the Segmented PWs draft.
>
> Regards,
>      Sasha
>

-- 
Sriganesh Kini (Sri)

---

From: "Delregno, Christopher N (Nick DelRegno)" <[email-masked]>
Date: Mon, 15 Nov 2010 17:32:51 +0000

Yaakov:

Thanks for the input.

The goal of my VCCV draft is to direct SUPPORT for the CC types, not
necessarily USE.  We have heard provider feedback that said even when CW
is mandatory, whether on existing implementations which require the CW
or in the future should it become globally mandatory, they still may
want to use other CC types.   So, I'm not sure we could mandate usage of
Type 1 where CW is mandatory.

Thanks,

Nick

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: Thursday, November 11, 2010 2:42 AM
To: [email-masked]
Subject: [PWE3] VCCV usage

Nick and all, 

and 2 MAY be used.

This reduces interop issues going forward, while not breaking existing
implementations without CWs.

Y(J)S

---

From: Luca Martini <[email-masked]>
Date: Mon, 15 Nov 2010 11:49:10 -0700

> It requires too much configuration, or alternatively a TTL discovery mechanism.
Yaakov,
TTL Expiry does not require any configuration, if you have a correct
implementation. All the information required is available from the
control plane. The user does not need to know how this is calculated.

If you have no LDP control plane , then there is surly an offline tool ,
like a gui/NMS that can also calculate this automatically for you.

Luca

---

From: Luca Martini <[email-masked]>
Date: Mon, 15 Nov 2010 11:50:37 -0700

> thus changing the number of PW hops.
yes , and the T_PE would know that, and adjust the VCCV packets accordingly.
Luca

---

From: Luca Martini <[email-masked]>
Date: Mon, 15 Nov 2010 11:59:26 -0700

Yaakov,

VCCV type 2 does not work for MS-PW. That is as close to depraceting it
as I could come without an update to the VCCV RFC. So we are in full
agreement on this point.

As for the number of PW hops changing:
The PW cannot change the number of hops ( TTL value requires for VCCV
packets ) without the T-PE ( and all S-PEs in the path ) knowing about
it. Either the PW is torn down , and setup again , or the T-PE switches
to a backup PW as explained in draft-ietf-pwe3-redundancy-03.txt.
Either way the required value of the TTL is always readily available.
Your concern is one of the main reasons why S-PEs cannot support
midpoint-backup-PWs.

Luca

On 11/12/10 05:08, Yaakov Stein wrote:
> *From:* Alexander Vainshtein [mailto:[email-masked]]
> *Sent:* Thursday, November 11, 2010 11:29
> *To:* Yaakov Stein
> *Cc:* [email-masked]
> *Subject:* RE: VCCV usage
>
> Yaakov and all,
>
> IMO when it comes to VCCV we should look for a disposition that would
> suit the needs of both single-segment and multi-segment PWs.
>
> VCCV Type 3 is the only technique that can support /segment-related
> OAM for multi-segment PWs/. This is explained in detail in the
> Segmented PWs
> <http://datatracker.ietf.org/doc/draft-ietf-pwe3-segmented-pw/?include_text=1>
> draft (now in the RFC Editor queue) with many examples, and it is not
> affected by presence or absence of the CW in encapsulation because
> S-PEs do not examine the CW. The same document also precludes usage of
> VCCV Type 2 for multi-segment PWs.
>
> When it comes to end-to-end (i.e., T-PE to T-PE) VCCV for MS-PWs, the
> only problem with VCCV Type 3 is the possibility of leaking a VCCV
> packet out of the PW if its TTL has not been set correctly by the
> transmitter. Hence the need to use VCCV Type 1 where possible.
>
> Channel Type.
> · Actively discourage usage of VCCV Type 2 as not compatible with MS-PWs
>
> · Promote /a combination of VCCV Type 3 and, where applicable, VCCV
> Type 1/ as an approach that meets the needs of both single-segment and
> multi-segment PWs.
>
> Regards,
>
> Sasha
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Yaakov Stein
> *Sent:* Thursday, November 11, 2010 10:42 AM
> *To:* [email-masked]
> *Subject:* [PWE3] VCCV usage
>
> Nick and all,
>

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 16 Nov 2010 04:46:23 +0000

> I am not sure why going to a different MPLS network in Yaakov's example would result 
> in replacing a single-segment PW with a multi-segment one. 
> IMO protection would probably happen at the tunnel level, not at the PW level.

Sasha

I owe you an explanation regarding this point (and my example was not an invented one, it is based on a customer requirement).

I fully agree with you that for a non-homogenous MPLS network running RSVP-TE
the easiest solution would be to create MPLS layer backups. 

However, there is the case of a SP entity providing PW services over a collection of MPLS networks
that are not directly under its control (for business reasons).  Setting up a segmented PW
as a backup can be done using only the PWE control protocol, and can be triggered based on
PWE level OAM conditions.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 16 Nov 2010 05:06:33 +0000

> yes , and the T_PE would know that, and adjust the VCCV packets accordingly.

Of course it CAN be done. 

It is simply a pain in the neck 
(and as you pointed out in your previous email, would require using some offline tool).

A pain in the neck that is not necessary if the CW identification method is used. 

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 16 Nov 2010 05:11:43 +0000

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

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Tue, 16 Nov 2010 09:49:21 +0100

It is also contrary to the text in RFC5085, which says about Type 1: "This
mode of VCCV operation MUST be supported when the control word is
present.", which I would interpret as "if you implement the control word,
you must implement type 1."

Matthew

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 16 Nov 2010 01:34:43 -0800

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 Nov 2010 11:37:51 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Tuesday, November 16, 2010 11:35 AM
To: Yaakov Stein
Cc: [email-masked]; Luca Martini
Subject: Re: [PWE3] VCCV usage

-- 
- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 16 Nov 2010 02:07:18 -0800

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.

-- 
- Sri

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 16 Nov 2010 06:54:02 -0500

That is correct. I believe this was the idea when we were doing the text, to 
provide firstly a baseline of support for implementations, and then a prioritized
list of other modes to fall back upon.

	--Tom

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Nov 2010 04:56:38 -0800

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 <[email-masked]
> wrote:

> Sriganesh Kini

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 Nov 2010 19:20:04 +0200

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 and which 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 approach here.

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:[email-masked]]
Sent: Tuesday, November 16, 2010 2:57 PM
To: Sriganesh Kini
Cc: Alexander Vainshtein; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Nov 16, 2010 at 1:37 AM, Alexander Vainshtein
<[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sriganesh Kini
> Cc: [email-masked]<mailto:[email-masked]>; Luca Martini
> On Mon, Nov 15, 2010 at 9:11 PM, Yaakov Stein <[email-masked]<mailto:[email-masked]>> wrote:
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
- Sri
_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Tue, 16 Nov 2010 18:46:16 +0100

Hi Sasha,

Please see below.

Matthew

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Tue, 16 Nov 2010 18:20:04 +0100
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, Yaakov Stein <[email-masked]<mailto:[email-masked]>>, Luca Martini <[email-masked]<mailto:[email-masked]>>, Sriganesh Kini <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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).

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

From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, November 16, 2010 2:57 PM
To: Sriganesh Kini
Cc: Alexander Vainshtein; [email-masked]<mailto:[email-masked]>; Yaakov Stein; Luca Martini
Subject: Re: [PWE3] VCCV usage

Dear Sri,

Regards,
Greg

On Tue, Nov 16, 2010 at 1:37 AM, Alexander Vainshtein
<[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]>[mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sriganesh Kini

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 16 Nov 2010 10:36:57 -0800

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)
<[email-masked]> wrote:
> Hi Sasha,
> Please see below.
> Matthew
> From: Alexander Vainshtein <[email-masked]>
> To: Greg Mirsky <[email-masked]>, Yaakov Stein <[email-masked]>,
> Luca Martini <[email-masked]>, Sriganesh Kini
> <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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).
>
>
>
> 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 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)
>
> 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.
>
>
>
> On Tue, Nov 16, 2010 at 2:07 AM, Sriganesh Kini
> <[email-masked]> wrote:
>
>> From: [email-masked][mailto:[email-masked]] On Behalf Of
>> Sriganesh Kini

-- 
- Sri

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 16 Nov 2010 14:16:52 -0500

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 <[email-masked]
> <mailto:[email-masked]>>
> To: Greg Mirsky <[email-masked] <mailto:[email-masked]>>,
> Yaakov Stein <[email-masked] <mailto:[email-masked]>>, Luca Martini
> <[email-masked] <mailto:[email-masked]>>, Sriganesh Kini
> <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> 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).
> 
>  
> 
> 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).
> 
> 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
> 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.
> 
>  
> 
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Tuesday, November 16, 2010 2:57 PM
> *To:* Sriganesh Kini
> *Cc:* Alexander Vainshtein; [email-masked] <mailto:[email-masked]>; Yaakov
> Stein; Luca Martini
> *Subject:* Re: [PWE3] VCCV usage
> 
>  
> 
> Dear Sri,
> 
> 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
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>> Yaakov, Sri,
>> From: [email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of Sriganesh Kini
>> Cc: [email-masked] <mailto:[email-masked]>; Luca Martini
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 16 Nov 2010 13:42:35 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Tuesday, November 16, 2010 1:37 PM
To: Bocci, Matthew (Matthew)
Cc: [email-masked]; 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) <[email-masked]> wrote:
> To: Greg Mirsky <[email-masked]>, Yaakov Stein 
> <[email-masked]>, Luca Martini <[email-masked]>, Sriganesh Kini 
> 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
> 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.
>
> 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).
>
> 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> 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.
> 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
> 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.
>
>> From: [email-masked][mailto:[email-masked]] On Behalf 
>> Of Sriganesh Kini
>>> All you have to do is set up the backup MS-PW, and trigger the 
>>> switch based on VCCV-BFD indications.
>>>
>>> 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
>>>
>>>

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 16 Nov 2010 13:47:39 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Pignataro
Sent: Tuesday, November 16, 2010 2:17 PM
To: Bocci, Matthew (Matthew)
Cc: Luca Martini; Yaakov Stein; [email-masked]
Subject: Re: [PWE3] VCCV usage

Sasha, Matthew, all,

Thanks,

-- Carlos.

On 11/16/2010 12:46 PM, Bocci, Matthew (Matthew) wrote:
> To: Greg Mirsky <[email-masked] 
> <mailto:[email-masked]>>, Yaakov Stein <[email-masked] 
> <mailto:[email-masked]>>, Luca Martini <[email-masked] 
> <mailto:[email-masked]>>, Sriganesh Kini 
> 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).
> 
>  
> 
> deprecated. If we accept this, an update to RFC 5085 (that defines 
> 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).
> 
> terminating some VCCV packets in S-PEs, with snooping on the 1^st 
> 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.
> thread from These differences were discussed in the following thread on the
> PWE3 list   from July this
> Type
> 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.
> 
> *Cc:* Alexander Vainshtein; [email-masked] <mailto:[email-masked]>; 
> Yaakov Stein; Luca Martini

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Nov 2010 14:11:01 -0600

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:[email-masked]] 
Sent: Tuesday, November 16, 2010 2:48 PM
To: Carlos Pignataro (cpignata); Bocci, Matthew (Matthew)
Cc: Luca Martini (lmartini); Yaakov Stein; [email-masked]
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-----
Carlos Pignataro

Sasha, Matthew, all,

Thanks,

-- Carlos.

> 1.       It seems that we more or less agree that VCCV Type 2 should
be

> thread from These differences were discussed in the following thread
on the

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 16 Nov 2010 15:19:29 -0600

Carlos,
The signaling of the CC Type is performed end-to-end. Therefore when a T-PE signals to the far-end T-PE that it can send and receive using CC Type 1, the S-PE must pass the VCCV capability unless its control plane cannot process a VCCV packet in the presence of the OAM control word but that is very unlikely. 

The key point in using CC Type 1 is to make sure that the egress T-PE can indendently, i.e., without relying on some other router to set the proper TTL value, intercept OAM packets of the provider and does not not forwarded them to the VPN customer.

The ability of the S-PE to perform exception handling on the data path based on VC label TTL expiry overrides other mechanisms because this is a fundamental operation of MPLS in a multi-hop path. That is why an S-PE must always be capable of doing it and does not need to be told via signaling from the T-PE node. In fact, it performs that for all packets, not just VCCV packets.

As for CC Type 2, it does not have the ability of targetting a specific S-PE beyond the first one. The router alert is inserted between the transport and VC labels and thus all VCCV packets get redirected to the control plane at the first S-PE node.

Regards,
Mustapha.

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2010 3:11 PM
To: Aissaoui, Mustapha (Mustapha); Bocci, Matthew (Matthew)
Cc: Luca Martini (lmartini); Yaakov Stein; [email-masked]
Subject: 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-----

Carlos,

Mustapha. 

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

Sasha, Matthew, all,

Thanks,

-- Carlos.

be

on the

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 16 Nov 2010 16:55:22 -0500

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) [[email-masked]]
Sent: Tuesday, November 16, 2010 11:42 AM
To: Sriganesh Kini; Bocci, Matthew (Matthew)
Cc: [email-masked]; Luca Martini; Yaakov Stein
Subject: RE: [PWE3] VCCV usage

Sri,

Mustapha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Tuesday, November 16, 2010 1:37 PM
To: Bocci, Matthew (Matthew)
Cc: [email-masked]; Luca Martini; Yaakov Stein
Subject: Re: [PWE3] VCCV usage

Matthew,

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Nov 2010 14:24:58 -0800

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 <[email-masked]

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Nov 2010 21:08:24 -0500

Hi Mustapha,

Please see inline. 

Thumb typed by Carlos Pignataro.

On Nov 16, 2010, at 4:19 PM, "Aissaoui, Mustapha (Mustapha)" <[email-masked]> wrote:

> Carlos,
> The signaling of the CC Type is performed end-to-end.

That is not what http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-18#section-9.4 says. If S-PEs modify-and-pass, it's not e2e signaling. 

> Therefore when a T-PE signals to the far-end T-PE that it can send and receive using CC Type 1, the S-PE must pass the VCCV capability unless its control plane cannot process a VCCV packet in the presence of the OAM control word but that is very unlikely. 

If an S-PE can remove a capability that bot T-PEs would otherwise support, it's not e2e but rather hop-by-hop. Taken to an extreme yet common case, if an S-PE does no support type 1 (as in not intercepting based on deep inspecting the CW) then TPEs cannot use it. That's my interpretation of that text. 

> The key point in using CC Type 1 is to make sure that the egress T-PE can indendently, i.e., without relying on some other router to set the proper TTL value, intercept OAM packets of the provider…

Exactly!

> The ability of the S-PE to perform exception handling on the data path based on VC label TTL expiry overrides other mechanisms because this is a fundamental operation of MPLS in a multi-hop path. T…

I agree with this premise, that basically it's most sensible to support type 3 at SPEs. Thats not what http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-18#section-9.5.1 seems to say though. Type 1 is independent of ttl, and ttl exception is type 3. 

Now, if there is an implicit capability not signaled, why are SPEs participating as clearing middle-men in the e2e signaling?

> As for CC Type 2, it does not have the ability of targetting a specific S-PE beyond the first one. The router alert is inserted between the transport and VC labels and thus all VCCV packets get red…

I agree that are intercepted at every hop. And that cannot target specific SPEs. This logic however should also obsolete CC Type 1, as CW 0x1 cannot tarted specific hop numbers. Stopping at each SPE (carrying the Target fec) can be a feature with appropriate processing rules. 

Thanks,

Carlos.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Nov 2010 07:47:55 +0200

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. (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). 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).
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 have already described a use case where such a combination would be useful.

Hopefully, these notes will be helpful.

Regards,
     Sasha

________________________________________
From: Carlos Pignataro [[email-masked]]
Sent: Tuesday, November 16, 2010 9:16 PM
To: Bocci, Matthew (Matthew)
Cc: Alexander Vainshtein; Greg Mirsky; Yaakov Stein; Luca Martini; Sriganesh Kini; [email-masked]
Subject: Re: [PWE3] VCCV usage

Sasha, Matthew, all,

Thanks,

-- Carlos.

---

From: Thomas Beckhaus <[email-masked]>
Date: Wed, 17 Nov 2010 08:24:39 +0100

Carlos, Sasha,

what is the intended addressing scheme of the 3 mechanism?

- VCCV type 3 it is easy: The node, where the TTL expires is addressed.
- VCCV type 1: Do we intend to address only the T-PE or do we expect to address any S-PE that may considers the VCCV header info and may respond? If the first case is right (and I think, it should be right), only in cases where the TTL expires on a S-PE (see above, but different addressing scheme), the VCCV frame with CW is processed on a S-PE. If we bet on layer violation, we can not guarantee to have an end-to end test.
- VCCV type 2: Do we intend to address only the first S-PE/T-PE which see and understand the alert label? The responding S-PE could be randomly, based on the support of the alert label.

In my opinion, there is the need to address every node on the path, all the S-PE and the T-PE to troubleshoot PW. With type 3+1, we have a simple solution for end-to-end (without TLL handling) monitoring and a powerful tool for S-PE segment (and also segments in the middle?) troubleshooting. All other cases are subject of layer violation (I would specify it with "a node inspects a frame, which was not addressed to him") and the result depends on the "support" of this layer violation.

Thomas

---

From: [email-masked]
Date: Wed, 17 Nov 2010 15:51:42 +0800

hi, all
why not consider type 2+ type 3 , for ms-pw , the S-PE firstly intercept 
the pakcet by TTL=1 of pw label.
then inspect whether the below label is         Router alert label. if 
yes, the packet will be delivered to 
control plane. or no, it will be dropped or processed on the data plane.

may my  understanding be wrong?

B.R. 
liu

Thomas Beckhaus <[email-masked]> 
发件人:  [email-masked]
2010-11-17 15:24

收件人
Alexander Vainshtein <[email-masked]>, Carlos Pignataro 
<[email-masked]>
抄送
Yaakov Stein <[email-masked]>, Martini <[email-masked]>, 
[email-masked], pwe3 <[email-masked]>, Thomas Beckhaus 
<[email-masked]>
主题
Re: [PWE3] VCCV usage

Carlos, Sasha,

- VCCV type 3 it is easy: The node, where the TTL expires is addressed.
- VCCV type 1: Do we intend to address only the T-PE or do we expect to 
address any S-PE that may considers the VCCV header info and may respond? 
If the first case is right (and I think, it should be right), only in 
cases where the TTL expires on a S-PE (see above, but different addressing 
scheme), the VCCV frame with CW is processed on a S-PE. If we bet on layer 
violation, we can not guarantee to have an end-to end test.
- VCCV type 2: Do we intend to address only the first S-PE/T-PE which see 
and understand the alert label? The responding S-PE could be randomly, 
based on the support of the alert label.

In my opinion, there is the need to address every node on the path, all 
the S-PE and the T-PE to troubleshoot PW. With type 3+1, we have a simple 
solution for end-to-end (without TLL handling) monitoring and a powerful 
tool for S-PE segment (and also segments in the middle?) troubleshooting. 
All other cases are subject of layer violation (I would specify it with "a 
node inspects a frame, which was not addressed to him") and the result 
depends on the "support" of this layer violation.

Thomas

Am 17.11.2010 um 06:47 schrieb Alexander Vainshtein:

> 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. (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). 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).
> 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 have already described a use case where such a 
combination would be useful.
> Hopefully, these notes will be helpful.
that,
>> is required is /ability to send  VCCV packets with the desired TTL 
value
>> terminating some VCCV packets in S-PEs, with snooping on the 1^st 
nibble
Type
>> expiration in the PW label stack entry MUST be on ACH type.  However, 
it
>> *Cc:* Alexander Vainshtein; [email-masked] <mailto:[email-masked]>; 
Yaakov

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Nov 2010 10:48:51 +0200

Liu,
RFC 3031 defines the behavior associated with the Router Alert label as following:
A value of 1 represents the "Router Alert Label".  This label value is legal anywhere in the label stack except at the bottom.  When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing.  The actual forwarding of the packet is determined by the label beneath it in the stack.  However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the "Router Alert Option" in IP packets [5].  Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol.

Since  placing the RA label below the PW label (hence at the bottom of the stack) is explicitly prohibited. I.e., your proposal explicitly contradicts the specification of RFC 3031.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 17, 2010 9:52 AM
To: Thomas Beckhaus
Cc: Alexander Vainshtein; Carlos Pignataro; Martini; [email-masked]; pwe3; [email-masked]; Thomas Beckhaus; Yaakov Stein
Subject: Re: [PWE3] VCCV usage

hi, all
why not consider type 2+ type 3 , for ms-pw , the S-PE firstly intercept the pakcet by TTL=1 of pw label.
then inspect whether the below label is         Router alert label. if yes, the packet will be delivered to
control plane. or no, it will be dropped or processed on the data plane.

B.R.
liu

2010-11-17 15:24

收件人

Alexander Vainshtein <[email-masked]>, Carlos Pignataro <[email-masked]>

抄送

Yaakov Stein <[email-masked]>, Martini <[email-masked]>, [email-masked], pwe3 <[email-masked]>, Thomas Beckhaus <[email-masked]>

主题

Re: [PWE3] VCCV usage

Carlos, Sasha,

Thomas

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 17 Nov 2010 13:40:39 -0600

Carlos,
I meant to say the VCCV capability options must be agreed upon by all nodes in the path of the MS-PW as explained in the draft.

There are two reasons for allowing an S-PE to filter out options of this capability. First, the T-PE does not know that the PW is a segmented MS-PW. So, it can insert all the CC Types. Only the S-PE knows it is doing stitching and thus can eliminate CC Type 2. The second reason is that it is more flexible that way to cater to different implementation constraints.

There is however one thing which is certainly causing us much confusion. When CC Type 3 was introduced in SS-PW, this was to indicate to the egress PE that if the VC-label had a TTL=1 then assume it is a VCCV packet and extract it from the data path. The reason why an explicit indication to the egress PE was required is because we are doing a POP of the label stack and the transport label does not have TTL=1. So, it is possible that some implementation may not perform exception handling at the VC label and will forward the packet to the AC. With an S-PE, it is somewhat different. It is swapping the VC label and thus a TTL expiry will most certainly cause exception handling and get the packet re-directed to the control plane. I would not however equate the exception handling procedure with CC Type 1. The former is required per MPLS LSR processing.

So an S-PE implementation may choose to pass both CC Types 1 and 3 and let the final outcome of the signaling be dictated by the T-PE nodes. I believe this is a simple and backward compatible with SS-PW at T-PE nodes.

Mustapha.

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, November 16, 2010 9:08 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: Bocci, Matthew (Matthew); Luca Martini (lmartini); Yaakov Stein; [email-masked]
Subject: Re: [PWE3] VCCV usage

Hi Mustapha,

Please see inline.

Exactly!

Thanks,

Carlos.

>> MB> Actually we should never snoop the first nibble unless TTL
>> MB> expires
>> year:
>> http://www.ietf.org/mail-archive/web/pwe3/current/msg11466.html)
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>

---

From: <[email-masked]>
Date: Thu, 18 Nov 2010 18:38:30 +0000

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Aissaoui, Mustapha (Mustapha)
> Sent: 17 November 2010 19:41
> To: Carlos Pignataro (cpignata)
> Cc: [email-masked]; Yaakov Stein; Luca Martini (lmartini)
> I meant to say the VCCV capability options must be agreed 
> upon by all nodes in the path of the MS-PW as explained in the draft.
NH=> The *nodes* in which layer network?  And how does one know which layer network one is in from looking only at the DP information?  Will this apply to both MPLS and MPLS-TP?

regards, Neil

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 18 Nov 2010 16:13:03 -0600

Neil,
This is specifically about the control plane signaling of VCCV capability in a MS-PW. So, these apply to S-PE nodes where two segments of a MS-PW are stitched.

Mustapha. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 18, 2010 1:39 PM
To: Aissaoui, Mustapha (Mustapha); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] VCCV usage

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Aissaoui, Mustapha (Mustapha)
> I meant to say the VCCV capability options must be agreed upon by all 
> nodes in the path of the MS-PW as explained in the draft.

regards, Neil

---

From: Sami Boutros <[email-masked]>
Date: Fri, 19 Nov 2010 22:56:04 -0800

You brought a good point about static MS-PWs,

For static MS-PWs at S-PE On TTL-Expiry..

1- Check if this is an ipv4 oam packet.
2- If the PW support CW, check if the 1st nibble = 0x0001,  if so 
then this is an oam.

Do you see any issue with doing the above?

Thanks,

Sami
At 02:13 PM 11/18/2010, Aissaoui, Mustapha (Mustapha) wrote:
>Neil,
>This is specifically about the control plane signaling of VCCV 
>capability in a MS-PW. So, these apply to S-PE nodes where two 
>segments of a MS-PW are stitched.
>
>Mustapha.
>
>NH=> The *nodes* in which layer network?  And how does one know 
>which layer network one is in from looking only at the DP 
>information?  Will this apply to both MPLS and MPLS-TP?
>
>regards, Neil

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 20 Nov 2010 16:43:40 +0200

Sami and all,
Looks OK to me.
were it not in strict contradiction with 5085, I'd even suggest checking for PW-ACH header regardless of CW usage.
since the exception mechanism has already identified the packet as not being a normal PW packet.
My 2c,
Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sami Boutros [[email-masked]]
Sent: Saturday, November 20, 2010 8:56 AM
To: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] VCCV usage

Thanks,

Sami

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 29 Nov 2010 10:04:34 -0500

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.
> 
> Regards, Sasha
> ________________________________________ From: Carlos Pignataro
> [[email-masked]] Sent: Tuesday, November 16, 2010 9:16 PM To:
> Bocci, Matthew (Matthew) Cc: Alexander Vainshtein; Greg Mirsky;
> Yaakov Stein; Luca Martini; Sriganesh Kini; [email-masked] Subject:
> Re: [PWE3] VCCV usage
> 
> Sasha, Matthew, all,
> 
> Please find a couple of top-post questions for my understanding of
> the thread:
> 
> 2. What are the reasons for deprecating CC Type 2, as for
> intercepting it works every time.
> 
>  fate-sharing, per
> <http://tools.ietf.org/html/rfc5085#section-5.1.3>.
> 
>> <mailto:[email-masked]>> Date: Tue, 16 Nov 2010
>> 18:20:04 +0100 To: Greg Mirsky <[email-masked]
>> <mailto:[email-masked]>> 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).
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 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.
>> 
>> thread from These differences were discussed in the following
>> thread on the PWE3 list   from July this year:
>>  (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.
>> 
>> 
>> 
>> *From:* Greg Mirsky [mailto:[email-masked]] *Sent:* Tuesday,
>> November 16, 2010 2:57 PM *To:* Sriganesh Kini *Cc:* Alexander
>> Vainshtein; [email-masked] <mailto:[email-masked]>; Yaakov Stein;
>> Luca Martini *Subject:* Re: [PWE3] VCCV usage
>> 
>> 
>> 
>> Dear Sri,
>> 
>> 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
>> 
>> monitoring and independently do a protection-switched resulting in
>> the number of hops changing for the segment.
>> 
>> 
>>> 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: [email-masked]
>>> Sent: Tuesday, November 16, 2010 11:35 AM To: Yaakov Stein Cc:
>>> [email-masked] <mailto:[email-masked]>; Luca Martini Subject: Re:
>>> [PWE3] VCCV usage
>>> 
>>>  packet, warps the label swap operation at S-PEs. It is best to
>>> stick to the standard MPLS label operations.
>>> 
>>>  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
>>> 
>>>>> Your concern is one of the main reasons why S-PEs cannot
>>>>> support midpoint-backup-PWs.
>>>> Luca
>>>> 
>>>> BTW, not ALL the S-PEs need to know. Only the S-PEs affected by
>>>> the
>> backup.
>>>> _______________________________________________ pwe3 mailing
>>>> list [email-masked] <mailto:[email-masked]> 
>>> _______________________________________________ pwe3 mailing list
>>> _______________________________________________ pwe3 mailing list
>> -- - Sri
>> _______________________________________________ pwe3 mailing list 
>> _______________________________________________ pwe3 mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________ pwe3 mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 29 Nov 2010 17:29:54 +0200

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:[email-masked]] 
Sent: Monday, November 29, 2010 5:05 PM
To: Alexander Vainshtein
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Martini; [email-masked]; [email-masked]
Subject: Re: [PWE3] VCCV usage

Sasha,

I agree with this.

Thanks,

-- Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 29 Nov 2010 10:29:46 -0500

Mustapha,

On 11/17/2010 2:40 PM, Aissaoui, Mustapha (Mustapha) wrote:
> Carlos, I meant to say the VCCV capability options must be agreed

I am sorry but I still do not see the need for this; in fact it seems
harmful.

Sasha said CC Type 1 can be used, if so negotiated, end-to-end (between
T-PEs). What you say contradicts that. If S-PEs do not peek deep in the
packet, why this signaling behavior?

> 
> There are two reasons for allowing an S-PE to filter out options of
> this capability. First, the T-PE does not know that the PW is a
> segmented MS-PW. So, it can insert all the CC Types. Only the S-PE
> knows it is doing stitching and thus can eliminate CC Type 2.

This can eliminate CC Type 1 as well.

> The
> second reason is that it is more flexible that way to cater to
> different implementation constraints.

I also do not understand this.

> 
> There is however one thing which is certainly causing us much
> confusion. When CC Type 3 was introduced in SS-PW, this was to
> indicate to the egress PE that if the VC-label had a TTL=1 then
> assume it is a VCCV packet and extract it from the data path. The
> reason why an explicit indication to the egress PE was required is
> because we are doing a POP of the label stack and the transport label
> does not have TTL=1. So, it is possible that some implementation may
> not perform exception handling at the VC label and will forward the
> packet to the AC.

Wouldn't that constitute a violation of MPLS forwarding?

Please note also that the signaling is not only advertising the
capability to intercept, but also the capability to process specific VCCVs.

> With an S-PE, it is somewhat different. It is
> swapping the VC label and thus a TTL expiry will most certainly cause
> exception handling and get the packet re-directed to the control
> plane. I would not however equate the exception handling procedure
> with CC Type 1. The former is required per MPLS LSR processing.
> 
> So an S-PE implementation may choose to pass both CC Types 1 and 3

So if an S-PE is using this signaling element for itself, how would an
S-PE intercept a packet based on the 1st nibble? If the S-PE is
modifying this information element "because they know what's best for
the T-PEs", is that really what we want?

Thanks,

-- Carlos.

> and let the final outcome of the signaling be dictated by the T-PE
> nodes. I believe this is a simple and backward compatible with SS-PW
> at T-PE nodes.
> 
> Mustapha.
> 
> -----Original Message----- From: Carlos Pignataro (cpignata)
> [mailto:[email-masked]] Sent: Tuesday, November 16, 2010 9:08 PM 
> To: Aissaoui, Mustapha (Mustapha) Cc: Bocci, Matthew (Matthew); Luca
> Martini (lmartini); Yaakov Stein; [email-masked] Subject: Re: [PWE3]
> VCCV usage
> 
> Hi Mustapha,
> 
> Please see inline.
> 
> On Nov 16, 2010, at 4:19 PM, "Aissaoui, Mustapha (Mustapha)"
> <[email-masked]> wrote:
> 
>> Carlos, The signaling of the CC Type is performed end-to-end.
> 
> That is not what
> http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-18#section-9.4
> says. If S-PEs modify-and-pass, it's not e2e signaling.
> 
>> Therefore when a T-PE signals to the far-end T-PE that it can send
>> and receive using CC Type 1, the S-PE must pass the VCCV capability
>> unless its control plane cannot process a VCCV packet in the
>> presence of the OAM control word but that is very unlikely.
> 
> If an S-PE can remove a capability that bot T-PEs would otherwise
> support, it's not e2e but rather hop-by-hop. Taken to an extreme yet
> common case, if an S-PE does no support type 1 (as in not
> intercepting based on deep inspecting the CW) then TPEs cannot use
> it. That's my interpretation of that text.
> 
>> The key point in using CC Type 1 is to make sure that the egress
>> T-PE can indendently, i.e., without relying on some other router to
>> set the proper TTL value, intercept OAM packets of the provider and
>> does not not forwarded them to the VPN customer.
> 
> Exactly!
> 
>> The ability of the S-PE to perform exception handling on the data
>> path based on VC label TTL expiry overrides other mechanisms
>> because this is a fundamental operation of MPLS in a multi-hop
>> path. That is why an S-PE must always be capable of doing it and
>> does not need to be told via signaling from the T-PE node. In fact,
>> it performs that for all packets, not just VCCV packets.
> 
> I agree with this premise, that basically it's most sensible to
> support type 3 at SPEs. Thats not what
> http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-18#section-9.5.1
> seems to say though. Type 1 is independent of ttl, and ttl exception
> is type 3.
> 
> Now, if there is an implicit capability not signaled, why are SPEs
> participating as clearing middle-men in the e2e signaling?
> 
>> As for CC Type 2, it does not have the ability of targetting a
>> specific S-PE beyond the first one. The router alert is inserted
>> between the transport and VC labels and thus all VCCV packets get
>> redirected to the control plane at the first S-PE node.
> 
> I agree that are intercepted at every hop. And that cannot target
> specific SPEs. This logic however should also obsolete CC Type 1, as
> CW 0x1 cannot tarted specific hop numbers. Stopping at each SPE
> (carrying the Target fec) can be a feature with appropriate
> processing rules.
> 
> Thanks,
> 
> Carlos.
> 
>> Regards, Mustapha.
>> 
>> -----Original Message----- From: Carlos Pignataro (cpignata)
>> [mailto:[email-masked]] Sent: Tuesday, November 16, 2010 3:11
>> PM To: Aissaoui, Mustapha (Mustapha); Bocci, Matthew (Matthew) Cc:
>> Luca Martini (lmartini); Yaakov Stein; [email-masked] Subject: 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:[email-masked]] Sent: Tuesday,
>> November 16, 2010 2:48 PM To: Carlos Pignataro (cpignata); Bocci,
>> Matthew (Matthew) Cc: Luca Martini (lmartini); Yaakov Stein;
>> [email-masked] 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.
>> 
>> [mailto:[email-masked]] On Behalf Of Carlos Pignataro Sent:
>> Tuesday, November 16, 2010 2:17 PM To: Bocci, Matthew (Matthew) Cc:
>> Luca Martini; Yaakov Stein; [email-masked] Subject: Re: [PWE3] VCCV
>> usage
>> 
>> Sasha, Matthew, all,
>> 
>> 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
>> 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
>>> <[email-masked]
>>> <mailto:[email-masked]>> Cc: "[email-masked]
>>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> 
>>> should
>>> deprecated. If we accept this, an update to RFC 5085 (that
>>> defines that, when multiple VCCV Types are supported, it is
>>> 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> 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: 
>>> 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.
>>> use cases for combining VCCV Type 1 and VCCV Type 3 that I have
>>> in mind.
>>> 
>>> 
>>> 
>>> *From:* Greg Mirsky [mailto:[email-masked]] *Sent:*
>>> Tuesday, November 16, 2010 2:57 PM *To:* Sriganesh Kini *Cc:*
>>> Alexander Vainshtein; [email-masked] <mailto:[email-masked]>; 
>>> 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
>>> 
>>> monitoring and independently do a protection-switched resulting
>>> in the number of hops changing for the segment.
>>> 
>>> 
>>>> monitoring using VCCV
>> Type 3?
>>>> 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 <[email-masked]
>>>> 
>>> <mailto:[email-masked]>> wrote:
>>>>> 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.
>>>  - --

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 29 Nov 2010 09:45:36 -0600

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)

   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:[email-masked]] 
Sent: Monday, November 29, 2010 10:30 AM
To: Carlos Pignataro (cpignata)
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Luca Martini (lmartini);
[email-masked]; [email-masked]
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:[email-masked]] 
Sent: Monday, November 29, 2010 5:05 PM
To: Alexander Vainshtein
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Martini; [email-masked];
[email-masked]

Sasha,

I agree with this.

Thanks,

-- Carlos.

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Nov 2010 13:10:00 -0800

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

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 29 Nov 2010 17:35:10 -0500

Hi Sri,

Thanks for the summary. Please see inline.

On 11/29/2010 4:10 PM, Sriganesh Kini wrote:
> 1. When a PW has a CW, CC Type 1 is obvious/implicit choice.

Or put a different way, CC Type 1 can only be used when the PW has a CW.
There's no implicit choice standardized though.

> However,

A PW label TTL expiry should trigger the exception mechanism to dealing
with a TTL expiration; this may include examining the PW-ACH for a VCCV
packet (or not), and may include detecting the VCCV packet but not
processing it for security if not advertised.

> 2. When PW does not have CW, CC Type 3 should be used.

According to RFC 5085, that should be Type 2 as preferred over Type 3
(see S5.1.2. and S7)

> When PWs were

I agree.

> ECMP behavior.

Exactly. Which prompts the question:

If the VCCV packet takes a different path than the PW data, can this
different path have a different number of hops and have the VCCV expire
at a PE different than the target PE?

> A draft that addresses this condition by extending TTL

Scanning now through this I-D, I could not find why a 'flow/entropy
label' [fat-pw] would not work.

Thanks,

-- Carlos.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2010 15:05:41 -0800

Dear Carlos,
you've written:
"If the VCCV packet takes a different path than the PW data, can this
different path have a different number of hops and have the VCCV expire
at a PE different than the target PE?"

I wouldn't say that path taken by VCCV packet is different from the path of
PW payload. If ECMP exists, VCCV packet will travel over one of available to
PW payload paths.
I think it is possible, though might be not realistic scenario, that number
of segments between pair of PEs is different over different paths of ECMP.

Regards,
Greg

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Nov 2010 15:15:46 -0800

Hi Carlos, pls see inline

> According to RFC 5085, that should be Type 2 as preferred over Type 3

Correct. I was referring to it more in the context of this thread
where Type-2 deprecation has been proposed.

> at a PE different than the target PE?

There can be different paths in the underlying MPLS PSN. However that
should not affect the TTL expiry of VCCV since the number of PW hops
must remain the same.

> label' [fat-pw] would not work.

Even with FAT-PW, when a CW is not present, an intermediate hop in the
MPLS PSN can look beyond the label stack and the data packet can take
a different path from the VCCV packet.

-- 
- Sri

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 30 Nov 2010 09:30:26 +0200

Greg, Carlos and all,
I am probably missing something important, but I see the situation when VCCV Type 3 may behave differently due to different number of hops on different ECMP paths somewhat problematic to me.

This is because the hop count for MS-PWs is the S-PE count, not the count of hops between one S-PE to another one.

In order to traverse a different number of S-PEs due to ECMP, you would need a combination of at least two elements:

 1.  Multiple S-PE paths being explicitly between the two T-PEs (for a given MS-PW). I am not even sure this is allowed by the MS-PW architecture today (even with fat PWs)
 2.  S-PEs doing ECMP on PW labels.

My 2c,

     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Greg Mirsky [[email-masked]]
Sent: Tuesday, November 30, 2010 1:05 AM
To: Carlos Pignataro
Cc: [email-masked]; Luca Martini (lmartini); Yaakov Stein; [email-masked]
Subject: Re: [PWE3] VCCV usage

Dear Carlos,
you've written:

I wouldn't say that path taken by VCCV packet is different from the path of PW payload. If ECMP exists, VCCV packet will travel over one of available to PW payload paths.
I think it is possible, though might be not realistic scenario, that number of segments between pair of PEs is different over different paths of ECMP.

Regards,
Greg

On Mon, Nov 29, 2010 at 2:35 PM, Carlos Pignataro <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sri,

I agree.

Thanks,

-- Carlos.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Nov 2010 23:41:03 -0800

Dear Sasha,
I was not sure whether different number of S-PEs between pair of PEs can
happen with ECMP myself. That's why "not realistic scenario".

Regards,
Greg

On Mon, Nov 29, 2010 at 11:30 PM, Alexander Vainshtein <
[email-masked]> wrote:

>  Greg, Carlos and all,
> I am probably missing something important, but I see the situation when
> VCCV Type 3 may behave differently due to different number of hops
> on different ECMP paths somewhat problematic to me.
>
> In order to traverse a different number of S-PEs due to ECMP, you would
> need a combination of at least two elements:
>
>    1. Multiple S-PE paths being explicitly between the two T-PEs (for a
>    given MS-PW). I am not even sure this is allowed by the MS-PW architecture
>    today (even with fat PWs)
>  ------------------------------
> *From:* [email-masked] [[email-masked]] On Behalf Of Greg
> Mirsky [[email-masked]]
> *Sent:* Tuesday, November 30, 2010 1:05 AM
> *To:* Carlos Pignataro
> *Cc:* [email-masked]; Luca Martini (lmartini); Yaakov Stein;
> [email-masked]
>
>  I wouldn't say that path taken by VCCV packet is different from the path
> of PW payload. If ECMP exists, VCCV packet will travel over one of available
> to PW payload paths.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 30 Nov 2010 11:56:13 +0200

Carlos,
Lots of  thanks for the clarification, it really helps to understand the intentions of the authors of 5085.
One (probably minor) thing that still is not clear to me, is the difference between the impact of ECMP on the data packets of a PW that does not use a CW and its impact on the VCCV (Type 3) packets in such a PW.

The first nibble of a data packet could actually be anything, and ECMP could be applied to (at least, some) such packets. E.g., if consider an ATM cell PW carrying VPI 0x4000 (from an NNI port of an ATM switch) and not using the CW, the fist nibble will be 4, and the same ECMP would be applied.

Of course this would mean that data packets would be dispersed somehow across the multiple paths, VCCV Type 3 would presumably take one of these paths.

Did I miss something?

Regards,
     Sasha

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Monday, November 29, 2010 5:46 PM
To: Alexander Vainshtein
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Luca Martini (lmartini); [email-masked]; [email-masked]
Subject: RE: [PWE3] VCCV usage

Sasha,

Does that clarify?

Thanks,

-- Carlos.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 29, 2010 10:30 AM
To: Carlos Pignataro (cpignata)
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Luca Martini (lmartini);

Carlos,
You've said that

Regards,
     Sasha

-----Original Message-----
From: Carlos Pignataro [mailto:[email-masked]]
Sent: Monday, November 29, 2010 5:05 PM
To: Alexander Vainshtein
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Martini; [email-masked];
[email-masked]

Sasha,

I agree with this.

Thanks,

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 30 Nov 2010 11:26:59 -0600

Hi Sasha,

I don't think you missed anything. For the PW without CW, the ECMP
treatment for data packets happens as per S2 of RFC 4928. For VCCV
packets in that case, ECMP treatment will be as per IPv4/IPv6 if the
core supports that, if the VCCV packet is IPv6/IPv6.

Thanks,

-- Carlos.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, November 30, 2010 4:56 AM
To: Carlos Pignataro (cpignata)
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Luca Martini (lmartini);

Carlos,
Lots of  thanks for the clarification, it really helps to understand the
intentions of the authors of 5085.
One (probably minor) thing that still is not clear to me, is the
difference between the impact of ECMP on the data packets of a PW that
does not use a CW and its impact on the VCCV (Type 3) packets in such a
PW.

The first nibble of a data packet could actually be anything, and ECMP
could be applied to (at least, some) such packets. E.g., if consider an
ATM cell PW carrying VPI 0x4000 (from an NNI port of an ATM switch) and
not using the CW, the fist nibble will be 4, and the same ECMP would be
applied.

Of course this would mean that data packets would be dispersed somehow
across the multiple paths, VCCV Type 3 would presumably take one of
these paths.

Did I miss something?

Regards,
     Sasha

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Monday, November 29, 2010 5:46 PM
To: Alexander Vainshtein
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Luca Martini (lmartini);

Sasha,

Does that clarify?

Thanks,

-- Carlos.

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, November 29, 2010 10:30 AM
To: Carlos Pignataro (cpignata)
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Luca Martini (lmartini);

Carlos,
You've said that

Regards,
     Sasha

-----Original Message-----
From: Carlos Pignataro [mailto:[email-masked]]
Sent: Monday, November 29, 2010 5:05 PM
To: Alexander Vainshtein
Cc: Bocci, Matthew (Matthew); Yaakov Stein; Martini; [email-masked];
[email-masked]

Sasha,

I agree with this.

Thanks,

-- Carlos.

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 30 Nov 2010 11:19:25 -0800

Carlos, Sasha et al,

To the point regd deprecating type2 VCCV, I believe it is good option
to retain and serves many purposes where the device cannot handle VCCV
packet based on TTL expiry. At present, it cannot be used in MSPW, but
doesn't mean it cannot be used at all (totally different topic altogether).

-sam

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Nov 2010 11:56:23 -0800

IMO, a PE cannot connect to two different PEs for the "same" PW. This
also holds true for any segment of that PW. Also, a PE cannot connect
to the same PE with different PW labels for the "same" PW. This too
holds true for any segment of that PW. It may be useful for the MS-PW
draft to clarify that. Note that this does not preclude a PW from
being a backup of another PW (possibly with different number of PW
hops).

The notion of different PW hops for any single PW due to ECMP should
not arise. Note that there may still be different number of hops in
the underlying MPLS PSN.

-- 
- Sri

On Mon, Nov 29, 2010 at 11:30 PM, Alexander Vainshtein
<[email-masked]> wrote:
> Greg, Carlos and all,
> I am probably missing something important, but I see the situation when VCCV
> Type 3 may behave differently due to different number of hops on different
> ECMP paths somewhat problematic to me.
>
> Multiple S-PE paths being explicitly between the two T-PEs (for a given
> MS-PW). I am not even sure this is allowed by the MS-PW architecture today
> (even with fat PWs)
> S-PEs doing ECMP on PW labels.
>
> My 2c,
>
>      Sasha
>
>

-- 
Sriganesh Kini (Sri)