Subject: [PWE3] Clarification request on VCCV CC types usage per PW

From: venkatesan mahalingam <[email-masked]>
Date: Mon, 12 Jul 2010 14:57:06 +0530

Hi PWE3 group,

In RFC-5085, section 5.3 VCCV capability advertisement for MPLS PWs, there
is no clarity about the CC type usage per PW.
So, can we have different CC type configurations per PW if the node supports
more than one CC types?

Example:
MPLS capable PW originating node supports all three CC types [1. ACH 2.
Router alert label 3. TTL expiry] for OAM packets demultiplexing.

In this case, please clarify the below configurations per PW is valid.

Can 3 PWs be setup with below configurations even though the PW originating
node supports all CC types?

1. PW-1 setup with ACH as CC type
2. PW-2 setup with Router alert label as CC type
3. PW-3 setup with TTL expiry as CC type

or

Does RFC mandate to send all supported CC types in all the three PWs?

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: "Anup Kumar Vasudevan (anuvasud)" <[email-masked]>
Date: Mon, 12 Jul 2010 21:05:47 +0530

Hi 

I believe that when multiple CC types are supported, it is upto the
vendor implemtation to advertise what is needed i.e. if vendor supports
all 3 modes then it can advertise all the 3 modes. If another vendor
supports only 1 then it needs to advertise only that. 

Now in a signaling case between the above 2 vendors, the common
implementation can be selected via signaling. 

Additionally if both support all the cases then this is the priority
used to select - 

   1.  Type 1: PWE3 Control Word with 0001b as first nibble (i.e. ACH)

   2.  Type 2: MPLS Router Alert Label

   3.  Type 3: MPLS PW Label with TTL == 1

Pl. see section 4 and 7 of the RFC for more details. 

Thanks 

Anup

From: [email-masked] [mailto:[email-masked]] On Behalf Of
venkatesan mahalingam
Sent: Monday, July 12, 2010 2:57 PM
To: [email-masked]
Subject: [PWE3] Clarification request on VCCV CC types usage per PW

Hi PWE3 group,

In RFC-5085, section 5.3 VCCV capability advertisement for MPLS PWs,
there is no clarity about the CC type usage per PW.

So, can we have different CC type configurations per PW if the node
supports more than one CC types?

Example:

Can 3 PWs be setup with below configurations even though the PW
originating node supports all CC types?

or 

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 12 Jul 2010 11:37:00 -0400

> Hi PWE3 group,
>  
> In RFC-5085, section 5.3 VCCV capability advertisement for MPLS PWs, there is no clarity about the CC type usage per PW.
> So, can we have different CC type configurations per PW if the node supports more than one CC types?
>  
> Example:
> MPLS capable PW originating node supports all three CC types [1. ACH 2. Router alert label 3. TTL expiry] for OAM packets demultiplexing.
>  
> Can 3 PWs be setup with below configurations even though the PW originating node supports all CC types?
>  

	The capability configuration is PER-PW, so the scenario you describe where one end is configured with 3 PWs (A,B,C) that are set up to support all types, and the other side of each PW (A_2, B_2, and C_3) that only support a specific CC type will work just fine.

> Does RFC mandate to send all supported CC types in all the three PWs?

	The RFC encourages you to reveal all supported modes so its more straight-forward to resolve the choice of which one to use. Alternatively, you can just configure one supported mode across your network and call it a day.

	--tom

> 
> 
> -- 
> Best Regards,
> Venkatesan Mahalingam.
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 12 Jul 2010 08:55:48 -0700

I don't think section 7 of RFC is entirely valid for multi-segment  
scenarios, where it says
"When multiple capabilities match, onlyone CC Type MUST be used."

One could have CC type 1 (CW) along with CC type 3 (ttl) i.e.  
type1+type3 could co-exist at the same time and the packets could be  
encapsulated that way.

-sam

On Jul 12, 2010, at 8:35 AM, Anup Kumar Vasudevan (anuvasud) wrote:

> vendor implemtation to advertise what is needed i.e. if vendor  
> supports all 3 modes then it can advertise all the 3 modes. If  
> another vendor supports only 1 then it needs to advertise only that.
>
> used to select –
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of venkatesan mahalingam
> MPLS capable PW originating node supports all three CC types [1. ACH  
> 2. Router alert label 3. TTL expiry] for OAM packets demultiplexing.
>

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 13 Jul 2010 12:07:41 -0500

Sam,
it is actually valid in the case of a MS-PW too. An S-PE node passes the VCCV capability signaled by the T-PE transparently and removes any type it does not support. Thus assuming that the S-PE node supports both CW and TTL=1 methods, the two T-PE nodes will advertise their capability and select one of the two (CW or TTL=1) to be used end-to-end across all segments of the MS-PW as if they were directly connected.

Regards,
Mustapha.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Monday, July 12, 2010 11:56 AM
To: Anup Kumar Vasudevan
Cc: [email-masked]; venkatesan mahalingam
Subject: Re: [PWE3] Clarification request on VCCV CC types usage per PW

I don't think section 7 of RFC is entirely valid for multi-segment scenarios, where it says
"When multiple capabilities match, onlyone CC Type MUST be used."

One could have CC type 1 (CW) along with CC type 3 (ttl) i.e. type1+type3 could co-exist at the same time and the packets could be encapsulated that way.

-sam

Hi
I believe that when multiple CC types are supported, it is upto the vendor implemtation to advertise what is needed i.e. if vendor supports all 3 modes then it can advertise all the 3 modes. If another vendor supports only 1 then it needs to advertise only that.
Now in a signaling case between the above 2 vendors, the common implementation can be selected via signaling.
Additionally if both support all the cases then this is the priority used to select -
   1.  Type 1: PWE3 Control Word with 0001b as first nibble (i.e. ACH)
   2.  Type 2: MPLS Router Alert Label
   3.  Type 3: MPLS PW Label with TTL == 1
Pl. see section 4 and 7 of the RFC for more details.
Thanks
Anup
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of venkatesan mahalingam
Sent: Monday, July 12, 2010 2:57 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [PWE3] Clarification request on VCCV CC types usage per PW
Hi PWE3 group,
In RFC-5085, section 5.3 VCCV capability advertisement for MPLS PWs, there is no clarity about the CC type usage per PW.
So, can we have different CC type configurations per PW if the node supports more than one CC types?
Example:
MPLS capable PW originating node supports all three CC types [1. ACH 2. Router alert label 3. TTL expiry] for OAM packets demultiplexing.
In this case, please clarify the below configurations per PW is valid.
Can 3 PWs be setup with below configurations even though the PW originating node supports all CC types?
1. PW-1 setup with ACH as CC type
2. PW-2 setup with Router alert label as CC type
3. PW-3 setup with TTL expiry as CC type
or
Does RFC mandate to send all supported CC types in all the three PWs?

--
Best Regards,
Venkatesan Mahalingam.
_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 13 Jul 2010 14:21:15 -0700

Mustapha,

I agree with the advertisement part but not with the selection of cc  
type.
Are you saying that, if type1 is selected, type3 cannot be used, which  
is what RFC says?
If so, how to ping an SPE with type1, without modifying ttl value  
(which is type3)?

My point is, type1 and type3 are not mutually exclusive but could co- 
exist.

-sam
On Jul 13, 2010, at 10:07 AM, Aissaoui, Mustapha (Mustapha) wrote:

> Sam,
> it is actually valid in the case of a MS-PW too. An S-PE node passes  
> the VCCV capability signaled by the T-PE transparently and removes  
> any type it does not support. Thus assuming that the S-PE node  
> supports both CW and TTL=1 methods, the two T-PE nodes will  
> advertise their capability and select one of the two (CW or TTL=1)  
> to be used end-to-end across all segments of the MS-PW as if they  
> were directly connected.
>
> Regards,
> Mustapha.
>
> Of Sam Aldrin
> type1+type3 could co-exist at the   same time and the packets could  
> be encapsulated that way.
>
> -sam
>
>> Additionally if both support all the cases then this is the  
>> priority used to select –
>> From: [email-masked] [mailto:[email-masked]] On  
>> Behalf Of venkatesan mahalingam
>> In RFC-5085, section 5.3 VCCV capability advertisement for MPLS  
>> PWs, there is no clarity about the CC type usage per PW.
>> MPLS capable PW originating node supports all three CC types [1.  
>> ACH 2. Router alert label 3. TTL expiry] for OAM packets  
>> demultiplexing.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 13 Jul 2010 21:54:37 -0400

I don't think that an "intersection of all sets" is the right approach for VCCV for MS-PW. Specifically, I think that:
1. We should differentiate e2e (T-PE to T-PE) from T-PE to S-PE-n in the capability intersection set; i.e., ability to trigger a specific S-PE to intercept the VCCV packet. 
2. It is different at S-PEs than SS-PW, because there is just switching and "deep inspection" of the CW is more expensive and RA would trigger every S-PE. A VCCV packet should be able to trigger which S-PE to process but be of zero cost to other S-PEs. 

Therefore, would it be sensible to craft the TTL value for S-PE probing, but use CW for e2e? And not optimal to use say CW for S-PEs but still maintain T-PE capability of CW?

Just my $0.02. Thanks,

Thumb typed by Carlos Pignataro.

On Jul 13, 2010, at 1:08 PM, "Aissaoui, Mustapha (Mustapha)" <[email-masked]> wrote:

> "When multiple 
>   capabilities match, onlyone CC Type 
>   MUST be used."
> 
> One could have CC 
>   type 1 (CW) along with CC type 3 (ttl) i.e. type1+type3 could co-exist at the 
>   same time and the packets could be encapsulated that way.
> 
> -sam
> 
>> Additionally if both support all the cases then this is the priority used to select –
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of venkatesan mahalingam

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 13 Jul 2010 19:56:47 -0700

Couldn't agree more, Carlos.

In other perspective, having TTL support (type3) is implicitly a must  
to have in the case of MS-PW.
Presence of CW(type1) or not, one should able to support type3, in  
order to effectively ping/trace SPE's and TPE in MS-PW.

Using RA label (type2) cannot work in MS-PW, as it will make packet to  
be punted at the very next hop(SPE).
Once comment inline with %SAM.

On Jul 13, 2010, at 6:54 PM, Carlos Pignataro (cpignata) wrote:

> I don't think that an "intersection of all sets" is the right  
> approach for VCCV for MS-PW. Specifically, I think that:
> 1. We should differentiate e2e (T-PE to T-PE) from T-PE to S-PE-n in  
> the capability intersection set; i.e., ability to trigger a specific  
> S-PE to intercept the VCCV packet.
> 2. It is different at S-PEs than SS-PW, because there is just  
> switching and "deep inspection" of the CW is more expensive and RA  
> would trigger every S-PE. A VCCV packet should be able to trigger  
> which S-PE to process but be of zero cost to other S-PEs.
>
> Therefore, would it be sensible to craft the TTL value for S-PE  
> probing, but use CW for e2e? And not optimal to use say CW for S-PEs  
> but still maintain T-PE capability of CW?
%SAM - Even if CW is present, while pinging SPE's, setting right TTL  
value will not cause any overhead or cost to other SPE's as the packet  
will get switched till the ttl is expired or reached TPE (whichever  
comes first). That way one need not chose different cc type for SPE  
and TPE. This is the point I was making i.e. type1+type3 could co-exist.

-sam
> On Jul 13, 2010, at 1:08 PM, "Aissaoui, Mustapha (Mustapha)" <[email-masked] 
> > wrote:
>
>> Sam,
>> it is actually valid in the case of a MS-PW too. An S-PE node  
>> passes the VCCV capability signaled by the T-PE transparently and  
>> removes any type it does not support. Thus assuming that the S-PE  
>> node supports both CW and TTL=1 methods, the two T-PE nodes will  
>> Behalf Of Sam Aldrin
>>> I believe that when multiple CC types are supported, it is upto  
>>> the vendor implemtation to advertise what is needed i.e. if vendor

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 14 Jul 2010 09:47:52 -0500

Carlos/Sam,
in fact TTL decrementing of the PW label is a fundamental part of the MS-PW operation and applies to both data and OAM packets. Any packet which TTL expired at a node must be extracted and examined. The TTL of a VCCV ping, regardless of which encapsulation method is used, must be set to the appropriate value if you want to ping an intermediate node.

The CW is a way of guaranteeing that the egress T-PE can identify and extract the packet even if the TTL is set to 255. A ping will typically use a TTL value of 255 since the user does not need to know how many hops away is the egress T-PE from the node, a T-PE or an S-PE, where the ping is issued. The TTL=1 method is not safe from this perspective since if the TTL is set to a higher value than the number of hops to the egress T-PE, the egress T-PE will actually forward the VCCV packet over the AC.

You are correct that the CW is absolutely not required if you are pinging an intermediate node in the path of a MS-PW since the control plane can parse the payload, e.g., MPLS echo request message based on destination UDP port. However, since a ping can be destined to any node in the network, including the egress T-PE, it was easier to allow for the singaling of a single encapsulation format to be used across all segments of the MS-PW.

When working on the VCCV section of draft-ietf-pwe3-segmented-pw, we originally described the CW option only. This however meant that the control word must be enabled on the PW even when the CW was optional, e.g., Ethernet PW. We later added the TTL=1 method mostly because of some deployment cases where the control word could not be enabled on PW types for which the control word is not mandatory, e.g., due to no support on the deployed routers. However, it is not a safe method as explained above.
Regards,
Mustapha.
________________________________
From: Sam   [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 10:57 PM
To: Carlos Pignataro
Cc: Aissaoui, Mustapha (Mustapha); Anup Kumar Vasudevan; [email-masked]; venkatesan mahalingam
Subject: Re: [PWE3] Clarification request on VCCV CC types usage per PW

In other perspective, having TTL support (type3) is implicitly a must to have in the case of MS-PW.
Presence of CW(type1) or not, one should able to support type3, in order to effectively ping/trace SPE's and TPE in MS-PW.

Using RA label (type2) cannot work in MS-PW, as it will make packet to be punted at the very next hop(SPE).
Once comment inline with %SAM.

Therefore, would it be sensible to craft the TTL value for S-PE probing, but use CW for e2e? And not optimal to use say CW for S-PEs but still maintain T-PE capability of CW?
%SAM - Even if CW is present, while pinging SPE's, setting right TTL value will not cause any overhead or cost to other SPE's as the packet will get switched till the ttl is expired or reached TPE (whichever comes first). That way one need not chose different cc type for SPE and TPE. This is the point I was making i.e. type1+type3 could co-exist.

-sam

Just my $0.02. Thanks,

On Jul 13, 2010, at 1:08 PM, "Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>> wrote:

Sam,

Regards,
Mustapha.

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Monday, July 12, 2010 11:56 AM
To: Anup Kumar Vasudevan
Cc: [email-masked]<mailto:[email-masked]>; venkatesan mahalingam
Subject: Re: [PWE3] Clarification request on VCCV CC types usage per PW

-sam

Hi
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of venkatesan mahalingam
To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

--
Best Regards,
Venkatesan Mahalingam.
_______________________________________________
pwe3 mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/pwe3>https://www.ietf.org/mailman/listinfo/pwe3

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 14 Jul 2010 10:59:29 -0700

Mustapha,

Comments inline with %SAM

On Jul 14, 2010, at 7:47 AM, Aissaoui, Mustapha (Mustapha) wrote:

> Carlos/Sam,
> in fact TTL decrementing of the PW label is a fundamental part of  
> the MS-PW operation and applies to both data and OAM packets. Any  
> packet which TTL expired at a node must be extracted and examined.  
> The TTL of a VCCV ping, regardless of which encapsulation method is  
> used, must be set to the appropriate value if you want to ping an  
> intermediate node.
>
> The CW is a way of guaranteeing that the egress T-PE can identify  
> and extract the packet even if the TTL is set to 255. A ping will  
> typically use a TTL value of 255 since the user does not need to  
> know how many hops away is the egress T-PE from the node, a T-PE or  
> an S-PE, where the ping is issued. The TTL=1 method is not safe from  
> this perspective since if the TTL is set to a higher value than the  
> number of hops to the egress T-PE, the egress T-PE will actually  
> forward the VCCV packet over the AC.
%SAM - If there is only type3 support w/o type1, then one should set  
the value of ttl to the right one. That is something issuer of ping  
should do, as the info is available via segment TLV. I do not see why  
user/sender has to set higher TTL value than the exact ttl value.
>
> You are correct that the CW is absolutely not required if you are  
> pinging an intermediate node in the path of a MS-PW since the  
> control plane can parse the payload, e.g., MPLS echo request message  
> based on destination UDP port. However, since a ping can be destined  
> to any node in the network, including the egress T-PE, it was easier  
> to allow for the singaling of a single encapsulation format to be  
> used across all segments of the MS-PW.
%SAM - setting ttl=255, when type1 is the supported cc type, should  
work, but not a cleaner method. If one has to ping a particular  
segment or far-end TPE, one should be aware of the segment info in  
order to fill in the FEC details. Which means, the info of how many  
segment hops away is also available. So, setting right ttl value is  
good practice.

If you look from reply via control channel perspective, on the  
replying router,  one should set right TTL value, irrespective of  
type1 or type3, because one do not know who the sender is i.e. SPE of  
TPE.  In order to be consistent, for both sending of replying, setting  
right TTL value, irrespective of cc type should be the way to go. CW  
or TTL, it should not matter or should there be a preferred option.

-sam
>
> When working on the VCCV section of draft-ietf-pwe3-segmented-pw, we  
> originally described the CW option only. This however meant that the  
> control word must be enabled on the PW even when the CW was  
> optional, e.g., Ethernet PW. We later added the TTL=1 method mostly  
> because of some deployment cases where the control word could not be  
> enabled on PW types for which the control word is not mandatory,  
> e.g., due to no support on the deployed routers. However, it is not  
> a safe method as explained above.
> Regards,
> Mustapha.
>> 1. We should differentiate e2e (T-PE to T-PE) from T-PE to S-PE-n  
>> in the capability intersection set; i.e., ability to trigger a  
>> specific S-PE to intercept the VCCV packet.
>> probing, but use CW for e2e? And not optimal to use say CW for S- 
>> PEs but still maintain T-PE capability of CW?
> value will not cause any overhead or cost to other SPE's as the  
> packet will get switched till the ttl is expired or reached TPE  
> (whichever comes first). That way one need not chose different cc  
> type for SPE and TPE. This is the point I was making i.e.  
> type1+type3 could co-exist.
>
> -sam
>>
>> Just my $0.02. Thanks,
>>
>>> One could         have CC type 1 (CW) along with CC type 3 (ttl)  
>>> i.e. type1+type3 could         co-exist at the same time and the  
>>> packets could be encapsulated that         way.
>>>
>>> -sam
>>>
>>>> the vendor implemtation to advertise what is needed i.e. if  
>>>> vendor supports all 3 modes then it can advertise all the 3  
>>>> modes. If another vendor supports only 1 then it needs to  
>>>> advertise only that.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 14 Jul 2010 18:30:50 -0500

Sam,
if you fill in the wrong FEC details, you get a reply from the egress T-PE with an error return code. If however you set the wrong TTL and the VCCV packet gets forwarded over the AC, you get no response and the sender times out. From a troubleshooting perspective, you want to prevent this situation.

As for a preferred option, note that when the CW is enabled on the PW, i.e., it is mandatory for this PW type or it is optional but CW is enabled by configuration, the VCCV packets must also have the CW. I thus do not think we can define a default option. Both are allowed in draft-ietf-pwe3-segmented-pw.

Mustapha.

________________________________
From: Sam Aldrin [mailto:[email-masked]]
Sent: Wednesday, July 14, 2010 1:59 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: Carlos Pignataro; Anup Kumar Vasudevan; [email-masked]; venkatesan mahalingam
Subject: Re: [PWE3] Clarification request on VCCV CC types usage per PW

Mustapha,

Carlos/Sam,

The CW is a way of guaranteeing that the egress T-PE can identify and extract the packet even if the TTL is set to 255. A ping will typically use a TTL value of 255 since the user does not need to know how many hops away is the egress T-PE from the node, a T-PE or an S-PE, where the ping is issued. The TTL=1 method is not safe from this perspective since if the TTL is set to a higher value than the number of hops to the egress T-PE, the egress T-PE will actually forward the VCCV packet over the AC.
%SAM - If there is only type3 support w/o type1, then one should set the value of ttl to the right one. That is something issuer of ping should do, as the info is available via segment TLV. I do not see why user/sender has to set higher TTL value than the exact ttl value.

You are correct that the CW is absolutely not required if you are pinging an intermediate node in the path of a MS-PW since the control plane can parse the payload, e.g., MPLS echo request message based on destination UDP port. However, since a ping can be destined to any node in the network, including the egress T-PE, it was easier to allow for the singaling of a single encapsulation format to be used across all segments of the MS-PW.
%SAM - setting ttl=255, when type1 is the supported cc type, should work, but not a cleaner method. If one has to ping a particular segment or far-end TPE, one should be aware of the segment info in order to fill in the FEC details. Which means, the info of how many segment hops away is also available. So, setting right ttl value is good practice.

If you look from reply via control channel perspective, on the replying router,  one should set right TTL value, irrespective of type1 or type3, because one do not know who the sender is i.e. SPE of TPE.  In order to be consistent, for both sending of replying, setting right TTL value, irrespective of cc type should be the way to go. CW or TTL, it should not matter or should there be a preferred option.

-sam

Cc: Aissaoui, Mustapha (Mustapha); Anup Kumar Vasudevan; [email-masked]<mailto:[email-masked]>; venkatesan mahalingam

-sam

Just my $0.02. Thanks,

Sam,

Regards,
Mustapha.

-sam

Hi

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 14 Jul 2010 16:53:32 -0700

Mustapha,

Inline for my comments.
On Jul 14, 2010, at 4:30 PM, Aissaoui, Mustapha (Mustapha) wrote:

> Sam,
> if you fill in the wrong FEC details, you get a reply from the  
> egress T-PE with an error return code. If however you set the wrong  
> TTL and the VCCV packet gets forwarded over the AC, you get no  
> response and the sender times out. From a troubleshooting  
> perspective, you want to prevent this situation.
you are describing the above for end-end ping, right? If the sender is  
SPE, you will receive timeout, if the 'reply' is sent with ttl=255,  
even with CW. Setting right ttl is implicit requirement, to make  
request and response consistent, in both type-1 and type3, to avoid  
timeouts or leaking packets onto AC.

-sam
>
> As for a preferred option, note that when the CW is enabled on the  
> PW, i.e., it is mandatory for this PW type or it is optional but CW  
> is enabled by configuration, the VCCV packets must also have the CW.  
> I thus do not think we can define a default option. Both are allowed  
> in draft-ietf-pwe3-segmented-pw.

>> an S-PE, where the ping is issued. The TTL=1 method is not safe  
>> from this perspective since if the TTL is set to a higher value  
>> than the number of hops to the egress T-PE, the egress T-PE will  
>> actually forward the VCCV packet over the AC.
> should do, as the info is available via segment TLV. I do not see  
> why user/sender has to set higher TTL value than the exact ttl value.
>>
>> control plane can parse the payload, e.g., MPLS echo request  
>> message based on destination UDP port. However, since a ping can be  
>> destined to any node in the network, including the egress T-PE, it  
>> was easier to allow for the singaling of a single encapsulation  
>> format to be used across all segments of the MS-PW.
> type1 or type3, because one do not know who the sender is i.e. SPE  
> of TPE.  In order to be consistent, for both sending of replying,  
> setting right TTL value, irrespective of cc type should be the way  
> to go. CW or TTL, it should not matter or should there be a  
> preferred option.
>
> -sam
>>
>> When working on the VCCV section of draft-ietf-pwe3-segmented-pw,  
>> we originally described the CW option only. This however meant that  
>> the control word must be enabled on the PW even when the CW was  
>> because of some deployment cases where the control word could not  
>> be enabled on PW types for which the control word is not mandatory,  
>> %SAM - Even if CW is present, while pinging SPE's, setting right  
>> TTL value will not cause any overhead or cost to other SPE's as the  
>>>> advertise their capability and select one of the two (CW or  
>>>> TTL=1) to be used end-to-end across all segments of the MS-PW as  
>>>> if they were directly connected.
>>>>
>>>> Regards,
>>>> Mustapha.
>>>>
>>>> One could             have CC type 1 (CW) along with CC type 3  
>>>> (ttl) i.e. type1+type3             could co-exist at the same  
>>>> time and the packets could be             encapsulated that way.
>>>>
>>>> -sam
>>>>

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 14 Jul 2010 20:14:32 -0500

Sam,
if the sender is not the ingress T-PE, the user can specify reply mode 2 - "Reply via an IPv4/IPv6 UDP packet" which causes the echo reply message to be routed to the sender.

Regards,
Mustapha.

Sent: Wednesday, July 14, 2010 7:54 PM

Mustapha,

Inline for my comments.

Sam,
if you fill in the wrong FEC details, you get a reply from the egress T-PE with an error return code. If however you set the wrong TTL and the VCCV packet gets forwarded over the AC, you get no response and the sender times out. From a troubleshooting perspective, you want to prevent this situation.
you are describing the above for end-end ping, right? If the sender is SPE, you will receive timeout, if the 'reply' is sent with ttl=255, even with CW. Setting right ttl is implicit requirement, to make request and response consistent, in both type-1 and type3, to avoid timeouts or leaking packets onto AC.

-sam

Mustapha.

Cc: Carlos Pignataro; Anup Kumar Vasudevan; [email-masked]<mailto:[email-masked]>; venkatesan mahalingam

Mustapha,

Carlos/Sam,

-sam

-sam

Just my $0.02. Thanks,

Sam,

Regards,
Mustapha.

-sam

Hi

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 14 Jul 2010 18:43:24 -0700

Mustapha,

Don't think that would work as segments could be in different AS  
domains and no ip route available.

When the replying router is TPE, and if the 'chosen' cctype is type1,  
are you saying that ttl should be set to 255?
How does the far end(replying router) know that the reply should go  
back to near-end TPE and not SPE?

cheers
-sam
On Jul 14, 2010, at 6:14 PM, Aissaoui, Mustapha (Mustapha) wrote:

> Sam,
> if the sender is not the ingress T-PE, the user can specify reply  
> mode 2 - "Reply via an IPv4/IPv6 UDP packet" which causes the echo  
> reply message to be routed to the sender.
>
> Regards,
> Mustapha.
>
> you are describing the above for end-end ping, right? If the sender  
> is SPE, you will receive timeout, if the 'reply' is sent with  
> ttl=255, even with CW. Setting right ttl is implicit requirement, to  
> make request and response consistent, in both type-1 and type3, to  
> avoid timeouts or leaking packets onto AC.
>
> -sam
>>
>> is enabled by configuration, the VCCV packets must also have the  
>> CW. I thus do not think we can define a default option. Both are  
>> allowed in draft-ietf-pwe3-segmented-pw.
>
>>
>> Mustapha.
>>
>>> The TTL of a VCCV ping, regardless of which encapsulation method  
>>> is used, must be set to the appropriate value if you want to ping  
>>> an intermediate node.
>>>
>>> know how many hops away is the egress T-PE from the node, a T-PE  
>>> or an S-PE, where the ping is issued. The TTL=1 method is not safe  
>> %SAM - If there is only type3 support w/o type1, then one should  
>> set the value of ttl to the right one. That is something issuer of  
>> ping should do, as the info is available via segment TLV. I do not  
>> see why user/sender has to set higher TTL value than the exact ttl  
>> value.
>>>
>>> message based on destination UDP port. However, since a ping can  
>>> be destined to any node in the network, including the egress T-PE,  
>>> it was easier to allow for the singaling of a single encapsulation  
>> replying router,  one should set right TTL value, irrespective  
>> of       type1 or type3, because one do not know who the sender is  
>> i.e. SPE of TPE.  In order to be consistent, for both sending of  
>> replying, setting right TTL value, irrespective of cc type should  
>> be the way to go. CW or TTL, it should not matter or should there  
>> be a preferred option.
>>
>> -sam
>>>
>>> we originally described the CW option only. This however meant  
>>> that the control word must be enabled on the PW even when the CW  
>>> was optional, e.g., Ethernet PW. We later added the TTL=1 method  
>>> mostly because of some deployment cases where the control word  
>>> could not be enabled on PW types for which the control word is not  
>>> mandatory, e.g., due to no support on the deployed routers.  
>>> However, it is not a safe method as explained above.
>>> Regards,
>>> Mustapha.
>>> Using RA label (type2) cannot work in MS-PW, as it will make  
>>> packet to be punted at the very next hop(SPE).
>>>> switching and "deep inspection" of the CW is more expensive and  
>>>> RA would trigger every S-PE. A VCCV packet should be able to  
>>>> trigger which S-PE to process but be of zero cost to other S-PEs.
>>>>
>>> TTL value will not cause any overhead or cost to other SPE's as  
>>> the packet will get switched till the ttl is expired or reached  
>>> TPE (whichever comes first). That way one need not chose different  
>>> cc type for SPE and TPE. This is the point I was making i.e.  
>>>>> passes the VCCV capability signaled by the T-PE transparently  
>>>>> and removes any type it does not support. Thus assuming that the  
>>>>> S-PE node supports both CW and TTL=1 methods, the two T-PE nodes  
>>>>> will advertise their capability and select one of the two (CW or  
>>>>> One                 could have CC type 1 (CW) along with CC type  
>>>>> 3 (ttl) i.e.                 type1+type3 could co-exist at the  
>>>>>> MPLS capable PW originating node supports all three CC types  
>>>>>> [1. ACH 2. Router alert label 3. TTL expiry] for OAM packets  
>>>>>> demultiplexing.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 14 Jul 2010 21:58:49 -0400

Mustapha,

Thanks for your response. 

I understood you said that (paraphrasing) "an S-PE takes the VCCV capability it received from a T-PE, clears the bits it does not support and passes it downstream to the next S-PE/T-PE". I understood that from when you wrote:
>>> An S-PE node passes the VCCV capability signaled by the T-PE transparently and removes any type it does not support.

I was saying that that method can blackhole capabilities. This is because there is a different switching function at T-PE (push/pop) than S-PE (swap). Therefore:
. CW is transparent (invisible) to S-PEs unless DPI. 
. TTL-- and check is inherent to the S-PE function
. RA will result is interception at every S-PE. 

And as such, TTL expiry interception seems to make more sense at S-PEs, but if not supported at T-PEs then it appears the "passing capability and clearing" would not work. 

Please find some more comments inline. 

> in fact TTL decrementing of the PW label is a fundamental part of the MS-PW operation and applies to both data and OAM packets. Any packet which TTL expired at a node must be extracted and examined…

This means type 3 support at S-PEs, even if not supported at T-PEs, correct? 

>  
> The CW is a way of guaranteeing that the egress T-PE can identify and extract the packet even if the TTL is set to 255. A ping will typically use a TTL value of 255 since the user does not need to know how many hops away is the egress T-PE from the node, a T-PE or an S-PE, where the ping is issued.

I'm not sure about qualifying as "typically", but the [TS]-PE does know how many S-PE hops away. 

> The TTL=1 method is not safe from this perspective since if the TTL is set to a higher value than the number of hops to the egress T-PE, the egress T-PE will actually forward the VCCV packet over the AC.

Then, would not setting the TTL higher than the number of switching hops inferred from the Swithing Point TLV solve the issue?

> You are correct that the CW is absolutely not required if you are pinging an intermediate node in the path of a MS-PW since the control plane can parse the payload, e.g., MPLS echo request message…

I am not sure I understand the above para. 

> When working on the VCCV section of draft-ietf-pwe3-segmented-pw, we originally described the CW option only. This however meant that the control word must be enabled on the PW even when the CW was…

The question I still have is why the interception method must be the same for T-PEs (e2e) than from probing an S-PE (where ttl seems to be the natural choice). 

Thanks,

-- Carlos. 

>>> "When 
>>>         multiple capabilities match, onlyone CC 
>>>         Type MUST be used."
>>> 
>>> One could 
>>>         have CC type 1 (CW) along with CC type 3 (ttl) i.e. type1+type3 could 
>>>         co-exist at the same time and the packets could be encapsulated that 
>>>         way.
>>> 
>>> -sam
>>>

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Thu, 15 Jul 2010 13:15:04 +0200

(Chairs hat off)

Carlos,

TTL expiry at the S-PEs is agnostic to whether CC type 3 or CC type 1 is in use along the MS-PW. CC type 1 does not use DPI at the S-PEs.

One issue for me is how you guarantee that the VCCV packet flow is bounded to the span of the PW. As you point out below, you can use the S-PE TLV to help set the TTL correctly, but only if every S-PE along the MS-PW sends that TLV. However, the S-PE TLV is optional, primarily for security reasons, so I do not think this is a reliable method of determining how many hops away the T-PE is. Do you really need to know the topology of the MS-PW for one end to ping the far end?

Also, I think we should remember that a major application for MS-PWs is inter-provider services. Is it safe that a T-PE should accept traffic onto an AC if an intermediate S-PE that is in another provider's domain sets the TTL incorrectly?

Thanks,

Matthew

From: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: 15 July 2010 02:59

Mustapha,

On Jul 14, 2010, at 10:48 AM, "Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>> wrote:

Carlos/Sam,

Thanks,

-- Carlos.

Regards,
Mustapha.

-sam

Just my $0.02. Thanks,

On Jul 13, 2010, at 1:08 PM, "Aissaoui, Mustapha (Mustapha)" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Sam,

Regards,
Mustapha.

________________________________
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Monday, July 12, 2010 11:56 AM
To: Anup Kumar Vasudevan
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; venkatesan mahalingam
Subject: Re: [PWE3] Clarification request on VCCV CC types usage per PW

-sam

Hi
From: <mailto:[email-masked]> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]><mailto:[email-masked]>mailto:[email-masked]] On Behalf Of venkatesan mahalingam
To: <mailto:[email-masked]> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

--
Best Regards,
Venkatesan Mahalingam.
_______________________________________________
pwe3 mailing list
<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/pwe3><https://www.ietf.org/mailman/listinfo/pwe3>https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 15 Jul 2010 08:59:28 -0500

Sam,
see below for some elements of response.

Mustapha.
Sent: Wednesday, July 14, 2010 9:43 PM

Mustapha,

Don't think that would work as segments could be in different AS domains and no ip route available.
MA>  if you are in an inter-AS/inter-provider use case and there is not route, it is also very unlikely that providers will allow the detailed information about their topology to be passed to the other AS in the S-PE TLV. That is why the S-PE TLV is optional. So, in this case there is no reliable way to determine the TTL back to the sender.
When the replying router is TPE, and if the 'chosen' cctype is type1, are you saying that ttl should be set to 255?
How does the far end(replying router) know that the reply should go back to near-end TPE and not SPE?

MA> the sender's IP address is in the header of the echo request message which is a UDP/IP message. The sender's address is also encoded in the Target Stack FEC TLV in the echo request message.

cheers
-sam

Sam,

Regards,
Mustapha.

Mustapha,

Inline for my comments.

Sam,

-sam

Mustapha.

Mustapha,

Carlos/Sam,

-sam

-sam

Just my $0.02. Thanks,

Sam,

Regards,
Mustapha.

-sam

Hi

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 15 Jul 2010 09:33:05 -0700

Matthew,

Couple of comments inline.
On Jul 15, 2010, at 4:15 AM, Bocci, Matthew (Matthew) wrote:

> (Chairs hat off)
>
> Carlos,
>
> TTL expiry at the S-PEs is agnostic to whether CC type 3 or CC type  
> 1 is in use along the MS-PW. CC type 1 does not use DPI at the S-PEs.
>
> One issue for me is how you guarantee that the VCCV packet flow is  
> bounded to the span of the PW. As you point out below, you can use  
> the S-PE TLV to help set the TTL correctly, but only if every S-PE  
> along the MS-PW sends that TLV. However, the S-PE TLV is optional,  
> primarily for security reasons, so I do not think this is a reliable  
> method of determining how many hops away the T-PE is. Do you really  
> need to know the topology of the MS-PW for one end to ping the far  
> end?
Why would you want to ping end to end when the information is blocked.  
Shouldn't the ping span only to the visible range?
Also, how do you distinguish between a end to end ping and non end to  
end ping?
Are you saying, if the segment info is not available, for both request  
and response, send with cw+ttl=255?
>
> Also, I think we should remember that a major application for MS-PWs  
> is inter-provider services. Is it safe that a T-PE should accept  
> traffic onto an AC if an intermediate S-PE that is in another  
> provider's domain sets the TTL incorrectly?
I would take it one step further and say, is it acceptable to ping a  
PE if the info is blocked/not available (in this case far end TPE info  
is not available via S-TLV).
I would say, the range should be limited to what the info is available.
That way, the request will not end up on AC or even on an node for  
which the segment info is not available.

-sam
> Of Carlos Pignataro (cpignata)
> Sent: 15 July 2010 02:59
> I understood you said that (paraphrasing) "an S-PE takes the VCCV  
> capability it received from a T-PE, clears the bits it does not  
> support and passes it downstream to the next S-PE/T-PE". I  
> understood that from when you wrote:
>>>> An S-PE node passes the VCCV capability signaled by the T-PE  
>>>> transparently and removes any type it does not support.
>
> I was saying that that method can blackhole capabilities. This is  
> because there is a different switching function at T-PE (push/pop)  
> than S-PE (swap). Therefore:
> And as such, TTL expiry interception seems to make more sense at S- 
> PEs, but if not supported at T-PEs then it appears the "passing  
> capability and clearing" would not work.
>
> On Jul 14, 2010, at 10:48 AM, "Aissaoui, Mustapha (Mustapha)" <[email-masked] 
> > wrote:
>
>> Carlos/Sam,
>> an S-PE, where the ping is issued.
>
>> The TTL=1 method is not safe from this perspective since if the TTL  
>> is set to a higher value than the number of hops to the egress T- 
>> PE, the egress T-PE will actually forward the VCCV packet over the  
>> AC.
>
> Then, would not setting the TTL higher than the number of switching  
> hops inferred from the Swithing Point TLV solve the issue?
>
>>
> The question I still have is why the interception method must be the  
> same for T-PEs (e2e) than from probing an S-PE (where ttl seems to  
> be the natural choice).
>
> Thanks,
>
> -- Carlos. 
>
>> Regards,
>> Mustapha.

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 15 Jul 2010 09:37:31 -0700

Mustapha,

Comments inline.
On Jul 15, 2010, at 6:59 AM, Aissaoui, Mustapha (Mustapha) wrote:

> MA>  if you are in an inter-AS/inter-provider use case and there is  
> not route, it is also very unlikely that providers will allow the  
> detailed information about their topology to be passed to the other  
> AS in the S-PE TLV. That is why the S-PE TLV is optional. So, in  
> this case there is no reliable way to determine the TTL back to the  
> sender.
That is exactly my point and should apply to the request as well. If  
the info is not available, why should request be sent with CW+ttl=255?
> When the replying router is TPE, and if the 'chosen' cctype is  
> type1, are you saying that ttl should be set to 255?
> MA> the sender's IP address is in the header of the echo request  
> message which is a UDP/IP message. The sender's address is also  
> encoded in the Target Stack FEC TLV in the echo request message.
source address in the ip header but not the  FEC TLV as it contains  
the segment info which is being pinged.
Again this is useful only if reply mode is ip, but doesn't help  
completely if it is via control channel.

-sam
>>> egress T-PE with an error return code. If however you set the  
>>> wrong TTL and the VCCV packet gets forwarded over the AC, you get  
>>> no response and the sender times out. From a troubleshooting  
>> ttl=255, even with CW. Setting right ttl is implicit requirement,  
>> to make request and response consistent, in both type-1 and type3,  
>> to avoid timeouts or leaking packets onto AC.
>>
>> -sam
>>>
>>> PW, i.e., it is mandatory for this PW type or it is optional but  
>>> CW is enabled by configuration, the VCCV packets must also have  
>>> the CW. I thus do not think we can define a default option. Both  
>>> are allowed in draft-ietf-pwe3-segmented-pw.
>>
>>>
>>> Mustapha.
>>>
>>>> packet which TTL expired at a node must be extracted and  
>>>> examined. The TTL of a VCCV ping, regardless of which  
>>>> encapsulation method is used, must be set to the appropriate  
>>>> value if you want to ping an intermediate node.
>>>>
>>>> or an S-PE, where the ping is issued. The TTL=1 method is not  
>>>> safe from this perspective since if the TTL is set to a higher  
>>>> value than the number of hops to the egress T-PE, the egress T-PE  
>>>> will actually forward the VCCV packet over the AC.
>>>> be destined to any node in the network, including the egress T- 
>>>> PE, it was easier to allow for the singaling of a single  
>>>> encapsulation format to be used across all segments of the MS-PW.
>>> %SAM - setting ttl=255, when type1 is the supported cc type,  
>>> should work, but not a cleaner method. If one has to ping a  
>>> particular segment or far-end TPE, one should be aware of the  
>>> segment info in order to fill in the FEC details. Which means, the  
>>> info of how many segment hops away is also available. So, setting  
>>> right ttl value is good practice.
>>>
>>>> could not be enabled on PW types for which the control word is  
>>>> not mandatory, e.g., due to no support on the deployed routers.  
>>>> Presence of CW(type1) or not, one should able to support type3,  
>>>> in order to effectively ping/trace SPE's and TPE in                
>>>> MS-PW.
>>>>
>>>>> 1. We should differentiate e2e (T-PE to T-PE) from T-PE to S-PE- 
>>>>> n in the capability intersection set; i.e., ability to trigger a  
>>>> TPE (whichever comes first). That way one need not chose  
>>>> different cc type for SPE and TPE. This is the point I was making  
>>>> i.e. type1+type3 could co-exist.
>>>>
>>>> -sam
>>>>>
>>>>> Just my $0.02. Thanks,
>>>>>
>>>>>> and removes any type it does not support. Thus assuming that  
>>>>>> the S-PE node supports both CW and TTL=1 methods, the two T-PE  
>>>>>> nodes will advertise their capability and select one of the two  
>>>>>> (CW or TTL=1) to be used end-to-end across all segments of the  
>>>>>> MS-PW as if they were directly connected.
>>>>>>
>>>>>> Regards,
>>>>>> Mustapha.
>>>>>>
>>>>>> One could have CC type 1 (CW) along                     with CC  
>>>>>> type 3 (ttl) i.e. type1+type3 could co-exist at  
>>>>>> the                     same time and the packets could be  
>>>>>> encapsulated that                     way.
>>>>>>
>>>>>> -sam
>>>>>>
>>>>>>> I believe that when multiple CC types are supported, it is  
>>>>>>> upto the vendor implemtation to advertise what is needed i.e.  
>>>>>>> if vendor supports all 3 modes then it can advertise all the 3  
>>>>>>> Now in a signaling case between the above 2 vendors, the  
>>>>>>> common implementation can be selected via signaling.
>>>>>>> In RFC-5085, section 5.3 VCCV capability advertisement for  
>>>>>>> MPLS PWs, there is no clarity about the CC type usage per PW.
>>>>>>> Can 3 PWs be setup with below configurations even though the  
>>>>>>> PW originating node supports all CC types?

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 15 Jul 2010 12:43:43 -0400

Matthew,

Thanks for the follow-up.

Please see inline; as this is more foundational than the initial
"cc_type_to_pass_ds = cc_type_received && local_capabilities" topic,
let's see if there's convergence.

On 7/15/2010 7:15 AM, Bocci, Matthew (Matthew) wrote:
> (Chairs hat off)
>  
> Carlos,
>  
> TTL expiry at the S-PEs is agnostic to whether CC type 3 or CC type 1 is
> in use along the MS-PW. CC type 1 does not use DPI at the S-PEs.

Yes and no. As I think there are two potential interpretations. Yes, TTL
expiration happens at S-PEs, including (when crafted that way) to VCCV
packets. But by definition, "CC Type" means the way in which the VCCV
packet is intercepted. This means, IMHO, that if the interception of the
VCCV packet to local inspection/processing at an S-PE happens due to TTL
expiry, then that's CC Type 3; if that PW uses a CW, then that CW needs
to include the first nibble as 0x1 matching CC Type 1 syntax. But that
does not mean it's CC Type 1.

http://tools.ietf.org/html/rfc5085#section-5.1.3

"5.1.3.  TTL Expiry VCCV (Type 3)
...
   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."

Conversely, if a VCCV packet uses the PW-ACH with the first nibble as
0x1, as in CC Type 1, with a high TTL (e.g., 255), then at an S-PE, just
by mere switching of PW Label the S-PE would not see the "CC Type 1",
unless it's inspecting beyond the actual function that is doing (what I
meant and didn't explain in detail as "DPI"). IOW, to have CC Type 1 at
S-PE we'd need an additional (deeper) forwarding behavior.

Do you agree?

> bounded to the span of the PW. As you point out below, you can use the
> S-PE TLV to help set the TTL correctly, but only if every S-PE along the
> MS-PW sends that TLV. However, the S-PE TLV is optional, primarily for
> security reasons, so I do not think this is a reliable method of
> determining how many hops away the T-PE is. Do you really need to know
> the topology of the MS-PW for one end to ping the far end?

This is correct, I agree, see below.

>  
> Also, I think we should remember that a major application for MS-PWs is
> inter-provider services. Is it safe that a T-PE should accept traffic
> onto an AC if an intermediate S-PE that is in another provider's domain
> sets the TTL incorrectly?

Yes, so perhaps the most comprehensive solution is to scope the
applicability of preferred modes? E.g., utilizing the S-PE TLV and TTL
setting for intra-AS scenarios, and other in inter-AS.

Like you say it's not safe to send traffic onto the AC; but would that
argue for managing the capability spaces independently between
end-to-end ping and intermediate-hop trace, and preferring CC Type 1 for
T-PE termination?

Thanks,

-- Carlos.

>  
> Thanks,
>  
> Matthew 
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Carlos Pignataro (cpignata)
>     *Sent:* 15 July 2010 02:59
>     *To:* Aissaoui, Mustapha (Mustapha)
>     *Cc:* [email-masked]; venkatesan mahalingam
>     *Subject:* Re: [PWE3] Clarification request on VCCV CC types usage
>     per PW
> 
>     Mustapha,
> 
>     And as such, TTL expiry interception seems to make more sense at
>     S-PEs, but if not supported at T-PEs then it appears the "passing
>     <mailto:[email-masked]>> wrote:
> 
>>     Carlos/Sam,
>>     encapsulation method is used, must be set to the appropriate value
>>     if you want to ping an intermediate node.
> 
>>     or an S-PE, where the ping is issued.
> 
>>     The TTL=1 method is not safe from this perspective since if the
>>     TTL is set to a higher value than the number of hops to the egress
>>     T-PE, the egress T-PE will actually forward the VCCV packet over
>>     the AC. 
> 
>>         ------------------------------------------------------------------------
>>         *From:* Sam   [mailto:[email-masked]]
>>         *Sent:* Tuesday, July 13, 2010 10:57 PM
>>         *To:* Carlos Pignataro
>>         *Cc:* Aissaoui, Mustapha (Mustapha); Anup Kumar Vasudevan;
>>         [email-masked] <mailto:[email-masked]>; venkatesan mahalingam
>>         *Subject:* Re: [PWE3] Clarification request on VCCV CC types
>>         usage per PW
>>
>>         Presence of CW(type1) or not, one should able to support
>>         type3, in order to effectively ping/trace SPE's and TPE in MS-PW.
>>
>>>         1. We should differentiate e2e (T-PE to T-PE) from T-PE to
>>>         S-PE-n in the capability intersection set; i.e., ability to
>>>         trigger a specific S-PE to intercept the VCCV packet. 
>>>         switching and "deep inspection" of the CW is more expensive
>>>         and RA would trigger every S-PE. A VCCV packet should be able
>>>         to trigger which S-PE to process but be of zero cost to other
>>>         S-PEs. 
>>>
>>>         Therefore, would it be sensible to craft the TTL value for
>>>         S-PE probing, but use CW for e2e? And not optimal to use say
>>>         CW for S-PEs but still maintain T-PE capability of CW?
>>         %SAM - Even if CW is present, while pinging SPE's, setting
>>         right TTL value will not cause any overhead or cost to other
>>         SPE's as the packet will get switched till the ttl is expired
>>         or reached TPE (whichever comes first). That way one need not
>>         chose different cc type for SPE and TPE. This is the point I
>>         was making i.e. type1+type3 could co-exist.
>>
>>         -sam
>>>
>>>         Just my $0.02. Thanks,
>>>
>>>         On Jul 13, 2010, at 1:08 PM, "Aissaoui, Mustapha (Mustapha)"
>>>         <
>>>         <mailto:[email-masked]>[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>>         Sam,
>>>>         it is actually valid in the case of a MS-PW too. An S-PE
>>>>         node passes the VCCV capability signaled by the T-PE
>>>>         transparently and removes any type it does not support. Thus
>>>>         assuming that the S-PE node supports both CW and TTL=1
>>>>         methods, the two T-PE nodes will advertise their capability
>>>>         and select one of the two (CW or TTL=1) to be used
>>>>         end-to-end across all segments of the MS-PW as if they were
>>>>         directly connected.
>>>>          
>>>>         Regards,
>>>>         Mustapha.
>>>>
>>>>             ------------------------------------------------------------------------
>>>>             *From:*
>>>>             <mailto:[email-masked]>[email-masked]
>>>>             <mailto:[email-masked]> [
>>>>             <mailto:[email-masked]>mailto:[email-masked]]
>>>>             *On Behalf Of *Sam Aldrin
>>>>             *Sent:* Monday, July 12, 2010 11:56 AM
>>>>             *To:* Anup Kumar Vasudevan
>>>>             *Cc:* <mailto:[email-masked]>[email-masked]
>>>>             <mailto:[email-masked]>; venkatesan mahalingam
>>>>             *Subject:* Re: [PWE3] Clarification request on VCCV CC
>>>>             types usage per PW
>>>>
>>>>>             I believe that when multiple CC types are supported, it
>>>>>             is upto the vendor implemtation to advertise what is
>>>>>             needed i.e. if vendor supports all 3 modes then it can
>>>>>             advertise all the 3 modes. If another vendor supports
>>>>>             only 1 then it needs to advertise only that.
>>>>>             Now in a signaling case between the above 2 vendors,
>>>>>             the common implementation can be selected via signaling.
>>>>>             *From:*  <mailto:[email-masked]>
>>>>>             <mailto:[email-masked]>[email-masked]
>>>>>             <mailto:[email-masked]> [
>>>>>             <mailto:[email-masked]>
>>>>>             <mailto:[email-masked]>mailto:[email-masked]] *On
>>>>>             Behalf Of *venkatesan mahalingam
>>>>>             *Sent:* Monday, July 12, 2010 2:57 PM
>>>>>             *To:*  <mailto:[email-masked]>
>>>>>             <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>             *Subject:* [PWE3] Clarification request on VCCV CC
>>>>>             types usage per PW
>>>>>             Hi PWE3 group,
>>>>>             In RFC-5085, section 5.3 VCCV capability advertisement
>>>>>             for MPLS PWs, there is no clarity about the CC type
>>>>>             usage per PW.
>>>>>             So, can we have different CC type configurations per PW
>>>>>             if the node supports more than one CC types?
>>>>>             Example:
>>>>>             MPLS capable PW originating node supports all three CC
>>>>>             types [1. ACH 2. Router alert label 3. TTL expiry] for
>>>>>             OAM packets demultiplexing.
>>>>>             Can 3 PWs be setup with below configurations even
>>>>>             though the PW originating node supports all CC types?
>>>>>             <mailto:[email-masked]>
>>>>>             <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>             <https://www.ietf.org/mailman/listinfo/pwe3>
>>>>         <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 15 Jul 2010 15:00:09 -0500

Sam,
see some follow-up below.

Mustapha.

Sent: Thursday, July 15, 2010 12:38 PM

Mustapha,

Comments inline.

Sam,

Mustapha.

Mustapha,

 That is exactly my point and should apply to the request as well. If the info is not available, why should request be sent with CW+ttl=255?
MA> The key point I am trying to convey is that you will need a way of making sure that the echo request and echo reply messages do not get forwarded over the AC when the sender node or replier node sets the wrong TTL value. This is even in the case when the S-PE TLV information is available but the sender or receiver inserts the wrong value.
The CW option achieves that since each T-PE can identify and extract VCCV messages based on the presence of the OAM CW.
When the replying router is TPE, and if the 'chosen' cctype is type1, are you saying that ttl should be set to 255?
How does the far end(replying router) know that the reply should go back to near-end TPE and not SPE?

MA> the sender's IP address is in the header of the echo request message which is a UDP/IP message. The sender's address is also encoded in the Target Stack FEC TLV in the echo request message.
source address in the ip header but not the  FEC TLV as it contains the segment info which is being pinged.
Again this is useful only if reply mode is ip, but doesn't help completely if it is via control channel.
MA> You are correct, the sender's address to use is the source IP address in the echo request message.

-sam

cheers
-sam

Sam,

Regards,
Mustapha.

Mustapha,

Inline for my comments.

Sam,

-sam

Mustapha.

Mustapha,

Carlos/Sam,

-sam

-sam

Just my $0.02. Thanks,

Sam,

Regards,
Mustapha.

-sam

Hi

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 15 Jul 2010 13:27:04 -0700

Mustapha,

One comment
<snipped for readability sake>
Mustapha wrote:
> MA> The key point I am trying to convey is that you will need a way  
> of making sure that the echo request and echo reply messages do not  
> get forwarded over the AC when the sender node or replier node sets  
> the wrong TTL value. This is even in the case when the S-PE TLV  
> information is available but the sender or receiver inserts the  
> wrong value.
> The CW option achieves that since each T-PE can identify and extract  
> VCCV messages based on the presence of the OAM CW.
>>
No disagreement about leaking packet onto AC, but I fail to see why it  
would leak onto AC  unless the negotiated cc_type is only type3. But  
more importantly I also consider sending packets to the device in  
MSPW, when it is not supposed to receive, as an issue as well. For ex:  
sending reply with CW+ttl=255, when it doesn't know who the source is,  
TPE/SPE.
If the negotiated cc types are type1 and type3, the packet will be  
sent with CW. So, even if wrong TTL(not sure how that could happen) is  
entered, the max it will reach is TPE. If it is just type3, I don't  
think there is any other option than setting to right ttl value. Hope  
there is no disagreement there.

I think the disagreement is whether to send cw+ttl=255 or not. I say  
we should only send to the segment, with right ttl set, for which the  
information is available. If it is not available mean, there is a good  
reason that AS/user do not want to exchange the data.

-sam
On Jul 15, 2010, at 1:00 PM, Aissaoui, Mustapha (Mustapha) wrote:

>  That is exactly my point and should apply to the request as well.  
> If the info is not available, why should request be sent with CW 
> +ttl=255?
> MA> The key point I am trying to convey is that you will need a way  
> of making sure that the echo request and echo reply messages do not  
> get forwarded over the AC when the sender node or replier node sets  
> the wrong TTL value. This is even in the case when the S-PE TLV  
> information is available but the sender or receiver inserts the  
> wrong value.
> The CW option achieves that since each T-PE can identify and extract  
> VCCV messages based on the presence of the OAM CW.
>>> you are describing the above for end-end ping, right? If the  
>>> sender is SPE, you will receive timeout, if the 'reply' is sent  
>>> with ttl=255, even with CW. Setting right ttl is implicit  
>>> requirement, to make request and response consistent, in both  
>>> type-1 and type3, to avoid timeouts or leaking packets onto AC.
>>>
>>> -sam
>>>>
>>>> As for a preferred option, note that when the CW is enabled on  
>>>> the PW, i.e., it is mandatory for this PW type or it is optional  
>>>> but CW is enabled by configuration, the VCCV packets must also  
>>>> have the CW. I thus do not think we can define a default option.  
>>>> Both are allowed in draft-ietf-pwe3-segmented-pw.
>>>
>>>>
>>>> Mustapha.
>>>>
>>>>> in fact TTL decrementing of the PW label is a fundamental part  
>>>>> of the MS-PW operation and applies to both data and OAM packets.  
>>>>> Any packet which TTL expired at a node must be extracted and  
>>>>> The CW is a way of guaranteeing that the egress T-PE can  
>>>>> identify and extract the packet even if the TTL is set to 255. A  
>>>>> ping will typically use a TTL value of 255 since the user does  
>>>>> not need to know how many hops away is the egress T-PE from the  
>>>>> node, a T-PE or an S-PE, where the ping is issued. The TTL=1  
>>>>> method is not safe from this perspective since if the TTL is set  
>>>>> to a higher value than the number of hops to the egress T-PE,  
>>>>> the egress T-PE will actually forward the VCCV packet over the AC.
>>>> set the value of ttl to the right one. That is something issuer  
>>>> of ping should do, as the info is available via segment TLV. I do  
>>>> not see why user/sender has to set higher TTL value than the  
>>>> exact ttl value.
>>>>>
>>>>> You are correct that the CW is absolutely not required if you  
>>>>> are pinging an intermediate node in the path of a MS-PW since  
>>>>> the control plane can parse the payload, e.g., MPLS echo request  
>>>> segment info in order to fill in the FEC details. Which means,  
>>>> the info of how many segment hops away is also available. So,  
>>>> setting right ttl value is good               practice.
>>>>
>>>> type1 or type3, because one do not know who the sender is i.e.  
>>>> SPE of TPE.  In order to be consistent, for both sending of  
>>>>> When working on the VCCV section of draft-ietf-pwe3-segmented- 
>>>>> pw, we originally described the CW option only. This however  
>>>>> meant that the control word must be enabled on the PW even when  
>>>>> the CW was optional, e.g., Ethernet PW. We later added the TTL=1  
>>>>> method mostly because of some deployment cases where the control  
>>>>> word could not be enabled on PW types for which the control word  
>>>>> is not mandatory, e.g., due to no support on the deployed  
>>>>> routers. However, it is not a safe method as explained above.
>>>>> Regards,
>>>>> Mustapha.
>>>>> in order to effectively ping/trace SPE's and TPE in MS-PW.
>>>>>
>>>>>> n in the capability intersection set; i.e., ability to trigger  
>>>>>> a specific S-PE to intercept the VCCV packet.
>>>>>> probing, but use CW for e2e? And not optimal to use say CW for  
>>>>>> S-PEs but still maintain T-PE capability of CW?
>>>>> different cc type for SPE and TPE. This is the point I was  
>>>>> making i.e. type1+type3 could co-exist.
>>>>>
>>>>> -sam
>>>>>>
>>>>>> Just my $0.02. Thanks,
>>>>>>
>>>>>>> nodes will advertise their capability and select one of the  
>>>>>>> two (CW or TTL=1) to be used end-to-end across all segments of  
>>>>>>> the MS-PW as if they were directly connected.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mustapha.
>>>>>>>
>>>>>>> "When                         multiple capabilities  
>>>>>>> match,                         onlyone CC  
>>>>>>> Type                         MUST be used."
>>>>>>>
>>>>>>> One could have CC type 1 (CW)                         along  
>>>>>>> with CC type 3 (ttl) i.e. type1+type3  
>>>>>>> could                         co-exist at the same time and  
>>>>>>> the packets could be                         encapsulated that  
>>>>>>> way.
>>>>>>>
>>>>>>> -sam
>>>>>>>
>>>>>>>> if vendor supports all 3 modes then it can advertise all the  
>>>>>>>> 3 modes. If another vendor supports only 1 then it needs to  
>>>>>>>> advertise only that.
>>>>>>>> So, can we have different CC type configurations per PW if  
>>>>>>>> the node supports more than one CC types?
>>>>>>>> Example:

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 15 Jul 2010 16:09:07 -0500

Sam,
it looks like we are in sync for most parts. See below for some more clarifications.

Mustapha.

Sent: Thursday, July 15, 2010 4:27 PM

Mustapha,

One comment
<snipped for readability sake>
Mustapha wrote:
MA> The key point I am trying to convey is that you will need a way of making sure that the echo request and echo reply messages do not get forwarded over the AC when the sender node or replier node sets the wrong TTL value. This is even in the case when the S-PE TLV information is available but the sender or receiver inserts the wrong value.
The CW option achieves that since each T-PE can identify and extract VCCV messages based on the presence of the OAM CW.
No disagreement about leaking packet onto AC, but I fail to see why it would leak onto AC  unless the negotiated cc_type is only type3. But more importantly I also consider sending packets to the device in MSPW, when it is not supposed to receive, as an issue as well. For ex: sending reply with CW+ttl=255, when it doesn't know who the source is, TPE/SPE.
MA> Absolutely, if the replier does not know the TTL back to the sender, then try use reply mode 2 if a route exists to the sender's IP address. If not, the reply should not be forwarded.

If the negotiated cc types are type1 and type3, the packet will be sent with CW. So, even if wrong TTL(not sure how that could happen) is entered, the max it will reach is TPE. If it is just type3, I don't think there is any other option than setting to right ttl value. Hope there is no disagreement there.

I think the disagreement is whether to send cw+ttl=255 or not. I say we should only send to the segment, with right ttl set, for which the information is available. If it is not available mean, there is a good reason that AS/user do not want to exchange the data.
 MA> When the CW option is used, then setting the TTL to 255 in the echo request message is just a matter of making sure you can reach the egress point of the MS-PW when you know the FEC of the last segment. Any value which is higher than or equal to the correct TTL value is fine.

-sam

Sam,

Mustapha.

Mustapha,

Comments inline.

Sam,

Mustapha.

Mustapha,

-sam

cheers
-sam

Sam,

Regards,
Mustapha.

Mustapha,

Inline for my comments.

Sam,

-sam

Mustapha.

Mustapha,

Carlos/Sam,

-sam

-sam

Just my $0.02. Thanks,

Sam,

Regards,
Mustapha.

-sam

Hi

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 15 Jul 2010 14:20:28 -0700

Mustapha,

Very good discussion so far.
Few more comments inline,
On Jul 15, 2010, at 2:09 PM, Aissaoui, Mustapha (Mustapha) wrote:

>> The CW option achieves that since each T-PE can identify and  
>> extract VCCV messages based on the presence of the OAM CW.
>>>
> No disagreement about leaking packet onto AC, but I fail to see why  
> it would leak onto AC  unless the negotiated cc_type is only type3.  
> But more importantly I also consider sending packets to the device  
> in MSPW, when it is not supposed to receive, as an issue as well.  
> For ex: sending reply with CW+ttl=255, when it doesn't know who the  
> source is, TPE/SPE.
> MA> Absolutely, if the replier does not know the TTL back to the  
> sender, then try use reply mode 2 if a route exists to the sender's  
> IP address. If not, the reply should not be forwarded.
The reply mode is chosen by the sender. So, it is not something which  
replying router could opt for. If request is received with 'reply on  
control channel', will TPE respond via control channel? if so with  
what ttl value?
> sent with CW. So, even if wrong TTL(not sure how that could happen)  
> is entered, the max it will reach is TPE. If it is just type3, I  
> don't think there is any other option than setting to right ttl  
> value. Hope there is no disagreement there.
>
> we should only send to the segment, with right ttl set, for which  
> the information is available. If it is not available mean, there is  
> a good reason that AS/user do not want to exchange the data.
>  MA> When the CW option is used, then setting the TTL to 255 in the  
> echo request message is just a matter of making sure you can reach  
> the egress point of the MS-PW when you know the FEC of the last  
> segment. Any value which is higher than or equal to the correct TTL  
> value is fine.
How did you learn the egress FEC/segment info? Also 1) is it good to  
send request when info is not available/exchanged due to S-TLV  
filtering etc.? 2) how can the reply arrive back via control channel,  
when the segment info is not exchanged (sorry I am hung up on this)?

cheers
-sam
>>> MA>  if you are in an inter-AS/inter-provider use case and there  
>>> is not route, it is also very unlikely that providers will allow  
>>> the detailed information about their topology to be passed to the  
>>> other AS in the S-PE TLV. That is why the S-PE TLV is optional.  
>>> So, in this case there is no reliable way to determine the TTL  
>>> back to the sender.
>>
>> The CW option achieves that since each T-PE can identify and  
>> extract VCCV messages based on the presence of the OAM CW.
>>>> mode 2 - "Reply via an IPv4/IPv6 UDP packet" which causes the  
>>>> echo reply message to be routed to the sender.
>>>>
>>>> Regards,
>>>> Mustapha.
>>>>
>>>>> wrong TTL and the VCCV packet gets forwarded over the AC, you  
>>>>> get no response and the sender times out. From a troubleshooting  
>>>>>> of the MS-PW operation and applies to both data and OAM  
>>>>>> packets. Any packet which TTL expired at a node must be  
>>>>>> extracted and examined. The TTL of a VCCV ping, regardless of  
>>>>>> which encapsulation method is used, must be set to the  
>>>>>> appropriate value if you want to ping an intermediate node.
>>>>>>
>>>>>> identify and extract the packet even if the TTL is set to 255.  
>>>>>> A ping will typically use a TTL value of 255 since the user  
>>>>>> does not need to know how many hops away is the egress T-PE  
>>>>>> from the node, a T-PE or an S-PE, where the ping is issued. The  
>>>>>> TTL=1 method is not safe from this perspective since if the TTL  
>>>>>> is set to a higher value than the number of hops to the egress  
>>>>>> T-PE, the egress T-PE will actually forward the VCCV packet  
>>>>>> over the AC.
>>>>> of ping should do, as the info is available via segment TLV. I  
>>>>> do not see why user/sender has to set higher TTL value than the  
>>>>> exact ttl value.
>>>>>>
>>>>>> the control plane can parse the payload, e.g., MPLS echo  
>>>>>> request message based on destination UDP port. However, since a  
>>>>>> ping can be destined to any node in the network, including the  
>>>>>> egress T-PE, it was easier to allow for the singaling of a  
>>>>>> single encapsulation format to be used across all segments of  
>>>>>> the MS-PW.
>>>>> replying, setting right TTL value, irrespective of cc type  
>>>>> should be the way to go. CW or TTL, it should not matter or  
>>>>> should there be a preferred option.
>>>>>
>>>>> -sam
>>>>>>
>>>>>> the CW was optional,                     e.g., Ethernet PW. We  
>>>>>> later added the TTL=1 method mostly because of some deployment  
>>>>>> cases where the control word could not be enabled on PW types  
>>>>>> for which the control word is not mandatory, e.g., due to no  
>>>>>> support on the deployed routers. However, it is not a safe  
>>>>>> method as explained above.
>>>>>> Regards,
>>>>>> Mustapha.
>>>>>>> 1. We should differentiate e2e (T-PE to T-PE) from T-PE to S- 
>>>>>>> PE-n in the capability intersection set; i.e., ability to  
>>>>>>> Therefore, would it be sensible to craft the TTL value for S- 
>>>>>>> PE probing, but use CW for e2e? And not optimal to use say CW  
>>>>>>> for S-PEs but still maintain T-PE capability of CW?
>>>>>>>> the S-PE node supports both CW and TTL=1 methods, the two T- 
>>>>>>>> PE nodes will advertise their capability and select one of  
>>>>>>>> the two (CW or TTL=1) to be used end-to-end across all  
>>>>>>>> segments of the MS-PW as if they were directly connected.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mustapha.
>>>>>>>>
>>>>>>>> match,                             onlyone  
>>>>>>>> CC                             Type MUST be used."
>>>>>>>>> upto the vendor implemtation to advertise what is needed  
>>>>>>>>> i.e. if vendor supports all 3 modes then it can advertise  
>>>>>>>>> all the 3 modes. If another vendor supports only 1 then it  
>>>>>>>>> needs to advertise only that.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 16 Jul 2010 11:43:09 -0500

Sam,
yes, this is a very good discussion. thanks.

I added a few elements of response below.

Regards,
Mustapha.

Sent: Thursday, July 15, 2010 5:20 PM

Mustapha,

Sam,

Mustapha.

Mustapha,

One comment
The reply mode is chosen by the sender. So, it is not something which replying router could opt for. If request is received with 'reply on control channel', will TPE respond via control channel? if so with what ttl value?

MA> I think this is more of an implementation/configuration thing. The responder node can be configured to attempt reply mode 2 in the case it cannot reliably reply using the 'reply on control channel'. The other option is in deployments where it is known that the S-PE TLV information may not be available/reliable to make sure that user always specifies reply mode 2 anytime it issues a VCCV ping message from any node other than the T-PE.

I think the disagreement is whether to send cw+ttl=255 or not. I say we should only send to the segment, with right ttl set, for which the information is available. If it is not available mean, there is a good reason that AS/user do not want to exchange the data.
 MA> When the CW option is used, then setting the TTL to 255 in the echo request message is just a matter of making sure you can reach the egress point of the MS-PW when you know the FEC of the last segment. Any value which is higher than or equal to the correct TTL value is fine.
How did you learn the egress FEC/segment info? Also 1) is it good to send request when info is not available/exchanged due to S-TLV filtering etc.? 2) how can the reply arrive back via control channel, when the segment info is not exchanged (sorry I am hung up on this)?

MA> In many cases, the user wants a basic connectivity check to the egress T-PE from any node in the path of the MS-PW.  So all what is needed is the FEC of the last segment to the egress T-PE and you set the TTL to 255 such that you do not have to figure it out for each node you are issuing the command from. You also set the reply mode to 2 if you issue it from a node other than the T-PE.
The last-segment FEC information is available through the provisioning system since each segment of the MS-PW must pe provisioned separately.
Any more elaborate connectivity checking or troubleshooting will require the use either the MS-PW Path Verification which parses the S-PE TLV information or the MS-PW Path Trace which learns the dowstream FEC hop-by-hop.

cheers
-sam

-sam

Sam,

Mustapha.

Mustapha,

Comments inline.

Sam,

Mustapha.

Mustapha,

-sam

cheers
-sam

Sam,

Regards,
Mustapha.

Mustapha,

Inline for my comments.

Sam,

-sam

Mustapha.

Mustapha,

Carlos/Sam,

-sam

-sam

Just my $0.02. Thanks,

Sam,

Regards,
Mustapha.

-sam

Hi

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 16 Jul 2010 10:12:37 -0700

Mustapha,

Comments inline.
On Jul 16, 2010, at 9:43 AM, Aissaoui, Mustapha (Mustapha) wrote:

>>> MA> The key point I am trying to convey is that you will need a  
>>> way of making sure that the echo request and echo reply messages  
>>> do not get forwarded over the AC when the sender node or replier  
>>> node sets the wrong TTL value. This is even in the case when the S- 
>>> PE TLV information is available but the sender or receiver inserts  
>>> the wrong value.
> The reply mode is chosen by the sender. So, it is not something  
> which replying router could opt for. If request is received with  
> 'reply on control channel', will TPE respond via control channel? if  
> so with what ttl value?
>
> MA> I think this is more of an implementation/configuration thing.  
> The responder node can be configured to attempt reply mode 2 in the  
> case it cannot reliably reply using the 'reply on control channel'.  
> The other option is in deployments where it is known that the S-PE  
> TLV information may not be available/reliable to make sure that user  
> always specifies reply mode 2 anytime it issues a VCCV ping message  
> from any node other than the T-PE.
Doesn't it contradict RFC4379, end of sec 4.5?
"Except in the case of Reply Mode 4, "Reply via application level
    control channel", echo replies are always sent in the context of the
    IP/MPLS network"

The main reason not to use reply mode 2 is that MSPW spans across  
multiple AS domains and having ip route across them is not common.
>> I think the disagreement is whether to send cw+ttl=255 or not. I  
>> say we should only send to the segment, with right ttl set, for  
>> which the information is available. If it is not available mean,  
>> there is a good reason that AS/user do not want to exchange the data.
> filtering etc.? 2) how can the reply arrive back via control  
> channel, when the segment info is not exchanged (sorry I am hung up  
> on this)?
>
> MA> In many cases, the user wants a basic connectivity check to the  
> egress T-PE from any node in the path of the MS-PW.  So all what is  
> needed is the FEC of the last segment to the egress T-PE and you set  
> the TTL to 255 such that you do not have to figure it out for each  
> node you are issuing the command from. You also set the reply mode  
> to 2 if you issue it from a node other than the T-PE.
> The last-segment FEC information is available through the  
> provisioning system since each segment of the MS-PW must pe  
> provisioned separately.
> Any more elaborate connectivity checking or troubleshooting will  
> require the use either the MS-PW Path Verification which parses the  
> S-PE TLV information or the MS-PW Path Trace which learns the  
> dowstream FEC hop-by-hop.
What you say is applicable only in one corner case i.e.
   - availability of ip route back to source, across AS domains

Why this is not generally applicable and standard shouldn't mandate  
this is for the following reasons
   - ip route is generally not present across AS domains
   - Sending with CW+ttl=255, doesn't work with reply mode 4, as  
replying router do not know, to whom the reply should go to.
   - It is not good to send lsp ping packets when the node/PE is not  
in the visible range.
   - It doesn't work if the negotiated cc type is only type3.

cheers
-sam
>>> MA> The key point I am trying to convey is that you will need a  
>>> way of making sure that the echo request and echo reply messages  
>>> do not get forwarded over the AC when the sender node or replier  
>>> node sets the wrong TTL value. This is even in the case when the S- 
>>> PE TLV information is available but the sender or receiver inserts  
>>> the wrong value.
>>> source address in the ip header but not the  FEC TLV as it  
>>> contains the segment info which is being pinged.
>>>>> if the sender is not the ingress T-PE, the user can specify  
>>>>> reply mode 2 - "Reply via an IPv4/IPv6 UDP packet" which causes  
>>>>> the echo reply message to be routed to the sender.
>>>>>
>>>>> Regards,
>>>>> Mustapha.
>>>>>
>>>>>> get no response and the sender times out. From a  
>>>>>> troubleshooting perspective, you want to prevent this situation.
>>>>>> the PW, i.e., it is mandatory for this PW type or it is  
>>>>>> optional but CW is enabled by configuration, the VCCV packets  
>>>>>> must also have the CW. I thus do not think we can define a  
>>>>>> default option. Both are allowed in draft-ietf-pwe3-segmented-pw.
>>>>>
>>>>>>
>>>>>> Mustapha.
>>>>>>
>>>>>>> identify and extract the packet even if the  
>>>>>>> TTL                         is set to 255. A ping will  
>>>>>>> typically use a TTL value of 255 since the user does not need  
>>>>>>> to know how many hops away is the egress T-PE from the node, a  
>>>>>>> T-PE or an S-PE, where the ping is issued. The TTL=1 method is  
>>>>>>> not safe from this perspective since if the TTL is set to a  
>>>>>>> higher value than the number of hops to the egress T-PE, the  
>>>>>>> egress T-PE will actually forward the VCCV packet over the AC.
>>>>>> %SAM - If there is only type3 support w/o type1, then one  
>>>>>> should set the value of ttl to the right one. That is something  
>>>>>> issuer of ping should do, as the info is available via segment  
>>>>>> TLV. I do not see why user/sender has to set higher TTL value  
>>>>>> than the exact ttl value.
>>>>>>>
>>>>>>> request message based on destination UDP port. However, since  
>>>>>>> a ping can be destined to any node in the network, including  
>>>>>>> the egress T-PE, it was easier to allow for the singaling of a  
>>>>>> i.e. SPE of TPE.  In order to be consistent, for both sending  
>>>>>> of replying, setting right TTL value, irrespective of cc type  
>>>>>>> meant that the control word must be enabled on the PW even  
>>>>>>> when the CW was optional, e.g., Ethernet PW. We later added  
>>>>>>> the TTL=1 method mostly because of some  
>>>>>>> deployment                         cases where the control  
>>>>>>> word could not be enabled on PW types for which the control  
>>>>>>> word is not mandatory, e.g., due to no support on the deployed  
>>>>>>>>> and select one of the two (CW or TTL=1) to be used end-to- 
>>>>>>>>> end across all segments of the MS-PW as if they were  
>>>>>>>>> directly connected.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Mustapha.
>>>>>>>>>
>>>>>>>>> i.e.                                 type1+type3 could co- 
>>>>>>>>> exist at the same time and                                  
>>>>>>>>> the packets could be encapsulated  
>>>>>>>>> that                                 way.
>>>>>>>>>
>>>>>>>>> -sam
>>>>>>>>>
>>>>>>>>>> types [1. ACH 2. Router alert label 3. TTL expiry] for OAM  
>>>>>>>>>> packets demultiplexing.
>>>>>>>>>> Can 3 PWs be setup with below configurations even though  
>>>>>>>>>> the PW originating node supports all CC types?

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 16 Jul 2010 15:25:54 -0500

Sam,
see below for some follow-up.

Mustapha.

Sent: Friday, July 16, 2010 1:13 PM

Mustapha,

Comments inline.

Sam,

Regards,
Mustapha.

Mustapha,

Sam,

Mustapha.

Mustapha,

One comment

MA> I do not think so.

The main reason not to use reply mode 2 is that MSPW spans across multiple AS domains and having ip route across them is not common.

MA> Well, if you do not have a route back to the sender or you do not have a way to determine the numer of hops to the sender, then you cannot do OAM. This is not specific to VCCV, it is true for LSP ping and other OAM tools.
Also, MS-PW are deployed in inter-AS networks that belong to the same provider. In that case, you expect to have a route if you want to do OAM. The other deployment case is in backhaul/metro networks where you want to scale the T-LDP adjacencies and routing separation is not required.

Why this is not generally applicable and standard shouldn't mandate this is for the following reasons
  - ip route is generally not present across AS domains
  - Sending with CW+ttl=255, doesn't work with reply mode 4, as replying router do not know, to whom the reply should go to.
  - It is not good to send lsp ping packets when the node/PE is not in the visible range.
  - It doesn't work if the negotiated cc type is only type3.

cheers
-sam

cheers
-sam

-sam

Sam,

Mustapha.

Mustapha,

Comments inline.

Sam,

Mustapha.

Mustapha,

-sam

cheers
-sam

Sam,

Regards,
Mustapha.

Mustapha,

Inline for my comments.

Sam,

-sam

Mustapha.

Mustapha,

Carlos/Sam,

-sam

-sam

Just my $0.02. Thanks,

Sam,

Regards,
Mustapha.

-sam

Hi

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 16 Jul 2010 14:54:37 -0700

Mustapha,

Few of my comments inline.
On Jul 16, 2010, at 1:25 PM, Aissaoui, Mustapha (Mustapha) wrote:

>>>> node sets the wrong TTL value. This is even in the case when the  
>>>> S-PE TLV information is available but the sender or receiver  
>>>> inserts the wrong value.
>>> No disagreement about leaking packet onto AC, but I fail to see  
>>> why it would leak onto AC  unless the negotiated cc_type is only  
>>> type3. But more importantly I also consider sending packets to the  
>>> device in MSPW, when it is not supposed to receive, as an issue as  
>>> well. For ex: sending reply with CW+ttl=255, when it doesn't know  
>>> who the source is, TPE/SPE.
>>> sender, then try use reply mode 2 if a route exists to the  
>>> sender's IP address. If not, the reply should not be forwarded.
>> 'reply on control channel', will TPE respond via control channel?  
>> if so with what ttl value?
>>
>> TLV information may not be available/reliable to make sure that  
>> user always specifies reply mode 2 anytime it issues a VCCV ping  
>> message from any node other than the T-PE.
%SAM - The way I understand is that the reply mode is chosen by sender  
and not the replier and if reply cannot be chosen mode, it should be  
dropped. Sure you could use reply mode 2 only while sending the  
request not a requirement That is some thing of implementors choice.
>>> sent with CW. So, even if wrong TTL(not sure how that could  
>>> happen) is entered, the max it will reach is TPE. If it is just  
>>> type3, I don't think there is any other option than setting to  
>>> right ttl value. Hope there is no disagreement there.
>>>
>>>  MA> When the CW option is used, then setting the TTL to 255 in  
>>> the echo request message is just a matter of making sure you can  
>>> reach the egress point of the MS-PW when you know the FEC of the  
>>> last segment. Any value which is higher than or equal to the  
>>> correct TTL value is fine.
>> How did you learn the egress FEC/segment info? Also 1) is it good  
>> to send request when info is not available/exchanged due to S-TLV  
>> egress T-PE from any node in the path of the MS-PW.        So all  
>> what is needed is the FEC of the last segment to the egress T-PE  
>> and you set the TTL to 255 such that you do not have to figure it  
>> out for each node you are issuing the command from. You also set  
>> the reply mode to 2 if you issue it from a node other than the T-PE.
> MA> Well, if you do not have a route back to the sender or you do  
> not have a way to determine the numer of hops to the sender, then  
> you cannot do OAM. This is not specific to VCCV, it is true for LSP  
> ping and other OAM tools.
Even while exchanging S-TLV's you cannot have hop count? You need not  
exchange all the routes to exchange S-TLV all along the MSPW.
> Also, MS-PW are deployed in inter-AS networks that belong to the  
> same provider. In that case, you expect to have a route if you want  
> to do OAM. The other deployment case is in backhaul/metro networks  
> where you want to scale the T-LDP adjacencies and routing separation  
> is not required.
Do we need to ignore if ip route is not enabled? I believe S-TLV fits  
exactly into the picture, where you could exchange segment info but  
not necessarily route info, across AS domains.

-sam
>>>>> the detailed information about their topology to be passed to  
>>>>> the other AS in the S-PE TLV. That is why the S-PE TLV is  
>>>>> optional. So, in this case there is no reliable way to determine  
>>>>> the TTL back to the sender.
>>>>
>>>>  That is exactly my point and should apply to the request as  
>>>> well. If the info is not available, why should request be sent  
>>>> with CW+ttl=255?
>>>> node sets the wrong TTL value. This is even in the case when the  
>>>> S-PE TLV information is available but the sender or receiver  
>>>> inserts the wrong value.
>>>>>>>> in fact TTL decrementing of the PW label is a fundamental  
>>>>>>>> part of the MS-PW operation and applies to both data and OAM  
>>>>>>>> identify and extract the packet even if  
>>>>>>>> the                             TTL is set to 255. A ping  
>>>>>>>> will typically use a TTL value of 255 since the user does not  
>>>>>>>> need to know how many hops away is the egress T-PE from the  
>>>>>>>> method is not safe from this perspective since if the TTL is  
>>>>>>>> set to a higher value than the number of hops to the egress T- 
>>>>>>>> PE, the egress T-PE will actually forward the VCCV packet  
>>>>>>>> over the AC.
>>>>>>> should set the value of ttl to the right one. That is  
>>>>>>> something issuer of ping should do, as the info is available  
>>>>>>> via segment TLV. I do not see why user/sender has to set  
>>>>>>> higher TTL value than the exact ttl value.
>>>>>>>>
>>>>>>>> the egress T-PE, it was easier to allow for the singaling of  
>>>>>>>> a single encapsulation format to be used across all segments  
>>>>>>>> of the MS-PW.
>>>>>>>> the TTL=1 method mostly because of some deployment cases  
>>>>>>>> where the control word could not be enabled on PW types for  
>>>>>>>> which the control word is not mandatory, e.g., due to no  
>>>>>>>> In other perspective, having TTL support (type3) is  
>>>>>>>> implicitly a must to have in the case of MS-PW.
>>>>>>>>> I don't think that an "intersection of all sets" is the  
>>>>>>>>> right approach for VCCV for MS-PW. Specifically, I think that:
>>>>>>>>> 2. It is different at S-PEs than SS-PW, because there is  
>>>>>>>>> just switching and "deep inspection" of the CW is more  
>>>>>>>>> expensive and RA would trigger every S-PE. A VCCV packet  
>>>>>>>>> should be able to trigger which S-PE to process but be of  
>>>>>>>>> zero cost to other S-PEs.
>>>>>>>>>
>>>>>>>>> PE probing, but use CW for e2e? And not optimal to use say  
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>> Sam,
>>>>>>>>>> Thus assuming that the S-PE node supports both CW and TTL=1

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Mon, 19 Jul 2010 16:34:16 -0500

Sam,
the VCCV tools as described in draft-ietf-pwe3-segmented-pw are flexible so that you can use the S-PE TLV when available and reliable but can also operate without it.

Regards,
Mustapha.

Sent: Friday, July 16, 2010 5:55 PM

Mustapha,

Sam,

Mustapha.

Mustapha,

Comments inline.

Sam,

Regards,
Mustapha.

Mustapha,

Sam,

Mustapha.

Mustapha,

One comment

MA> I do not think so.

%SAM - The way I understand is that the reply mode is chosen by sender and not the replier and if reply cannot be chosen mode, it should be dropped. Sure you could use reply mode 2 only while sending the request not a requirement That is some thing of implementors choice.

MA> Well, if you do not have a route back to the sender or you do not have a way to determine the numer of hops to the sender, then you cannot do OAM. This is not specific to VCCV, it is true for LSP ping and other OAM tools.
Even while exchanging S-TLV's you cannot have hop count? You need not exchange all the routes to exchange S-TLV all along the MSPW.
Also, MS-PW are deployed in inter-AS networks that belong to the same provider. In that case, you expect to have a route if you want to do OAM. The other deployment case is in backhaul/metro networks where you want to scale the T-LDP adjacencies and routing separation is not required.
Do we need to ignore if ip route is not enabled? I believe S-TLV fits exactly into the picture, where you could exchange segment info but not necessarily route info, across AS domains.

-sam