Subject: Re: [PWE3] VCCV usage

From: [email-masked]
Date: Wed, 17 Nov 2010 11:35:44 +0800

Hi all,
I agree with Mustapha's statement about TTL expiry for S-PE. 
For MS-PW, IMO, CC type 1 MUST be deployed and negotiated in order to 
avoid leaking packets to AC, and CC Type 3 is not necessary to be 
negotiated.
The S-PE behavior is like below:
When S-PE receives packets with TTL=1, it should check whether this PW 
support CW, if it does, it will check the nibble. If the packets are data 
packets, it may discard the packets. If it is control packet, send it to 
control plane. 
If this PW does not support CW, then it check if CC type 3 is supported by 
this PW. If CC type 3 is supported, S-PE should check if the packet is IP 
packet, if it is, send the packet to control plane, if it is not, it may 
discard the packet.

I think the T-PE behavior is quite clear for us. If CW is supported, it 
should always check the niblle. If only CC type 3 is supported, the packet 
with TTL=1 will be sent to control plane if it is IP packet.

We should not confuse the TTL expiry behavior between when it combining 
with CW and CC type3.

Lizhong

> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 16 Nov 2010 15:19:29 -0600
> From: "Aissaoui, Mustapha (Mustapha)"
>    <[email-masked]>
> Subject: Re: [PWE3] VCCV usage
> To: "Carlos Pignataro (cpignata)" <[email-masked]>, "Bocci,
>    Matthew   (Matthew)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Yaakov Stein <[email-masked]>,
>    "Luca Martini \(lmartini\)" <[email-masked]>
> Message-ID:
>    <[email-masked].
> alcatel-lucent.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> Carlos,
> The signaling of the CC Type is performed end-to-end. Therefore when
> a T-PE signals to the far-end T-PE that it can send and receive 
> using CC Type 1, the S-PE must pass the VCCV capability unless its 
> control plane cannot process a VCCV packet in the presence of the 
> OAM control word but that is very unlikely. 
> 
> The key point in using CC Type 1 is to make sure that the egress T-
> PE can indendently, i.e., without relying on some other router to 
> set the proper TTL value, intercept OAM packets of the provider and 
> does not not forwarded them to the VPN customer.
> 
> The ability of the S-PE to perform exception handling on the data 
> path based on VC label TTL expiry overrides other mechanisms because
> this is a fundamental operation of MPLS in a multi-hop path. That is
> why an S-PE must always be capable of doing it and does not need to 
> be told via signaling from the T-PE node. In fact, it performs that 
> for all packets, not just VCCV packets.
> 
> As for CC Type 2, it does not have the ability of targetting a 
> specific S-PE beyond the first one. The router alert is inserted 
> between the transport and VC labels and thus all VCCV packets get 
> redirected to the control plane at the first S-PE node.
> 
> Regards,
> Mustapha.
> 

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Nov 2010 08:03:20 +0200

Hi all,
It seems that I have been wrong when I have said that combining VCCV Type 1 and VCCV Type 3 requires only some transmit capabilities. VCCV Type 1 indeed means that T-PE always examines the first nibble of the CW on receive.

At the same time I think that VCCV Type 3 in the presence of CW still has to be negotiated.
Otherwise the CP that intercepts a VCCV packet due to TTL expiration could possibly treat it as a potential IP packet, find an invalid IP header and discard the packet as an error.  So advertizing VCCV Type 3 for a PW that uses CW means that first nibble set to 0b0001 would be considered as valid, and the packet would be further processed based on the ACH type in the PW-ACH header.

Maybe we need additional clarification on expected behavior of combinations of VCCV Type 1 and VCCV Type 3.

Regards,
     Sasha
________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Wednesday, November 17, 2010 5:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] VCCV usage

Hi all,
I agree with Mustapha's statement about TTL expiry for S-PE.
For MS-PW, IMO, CC type 1 MUST be deployed and negotiated in order to avoid leaking packets to AC, and CC Type 3 is not necessary to be negotiated.
The S-PE behavior is like below:
When S-PE receives packets with TTL=1, it should check whether this PW support CW, if it does, it will check the nibble. If the packets are data packets, it may discard the packets. If it is control packet, send it to control plane.
If this PW does not support CW, then it check if CC type 3 is supported by this PW. If CC type 3 is supported, S-PE should check if the packet is IP packet, if it is, send the packet to control plane, if it is not, it may discard the packet.

I think the T-PE behavior is quite clear for us. If CW is supported, it should always check the niblle. If only CC type 3 is supported, the packet with TTL=1 will be sent to control plane if it is IP packet.

We should not confuse the TTL expiry behavior between when it combining with CW and CC type3.

Lizhong

---

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

Hi Sasha,
>From my understanding, if VCCV Type 1 is supported without type 3 
negotiated on this PW, S-PE should still always check the nibble for the 
TTL expiry packet. Then it will not treat it as potential IP packet. It is 
VCCV type 1 which enables S-PE to check the nibble.

BR
Lizhong

Alexander Vainshtein <[email-masked]> wrote on 
2010-11-17 14:03:20:

> Hi all,
> It seems that I have been wrong when I have said that combining VCCV
> Type 1 and VCCV Type 3 requires only some transmit capabilities. 
> VCCV Type 1 indeed means that T-PE always examines the first nibble 
> of the CW on receive. 
> 
> Otherwise the CP that intercepts a VCCV packet due to TTL expiration
> could possibly treat it as a potential IP packet, find an invalid IP
> header and discard the packet as an error. So advertizing VCCV Type
> 3 for a PW that uses CW means that first nibble set to 0b0001 would 
> be considered as valid, and the packet would be further processed 
> based on the ACH type in the PW-ACH header.
> 
> Maybe we need additional clarification on expected behavior of 
> combinations of VCCV Type 1 and VCCV Type 3.
> 
> Regards,
>      Sasha
> 
> From: [email-masked] [[email-masked]] On Behalf Of 
> [email-masked] [[email-masked]]

> For MS-PW, IMO, CC type 1 MUST be deployed and negotiated in order 
> to avoid leaking packets to AC, and CC Type 3 is not necessary to be
> negotiated. 
> When S-PE receives packets with TTL=1, it should check whether this 
> PW support CW, if it does, it will check the nibble. If the packets 
> are data packets, it may discard the packets. If it is control 
> packet, send it to control plane. 
> If this PW does not support CW, then it check if CC type 3 is 
> supported by this PW. If CC type 3 is supported, S-PE should check 
> if the packet is IP packet, if it is, send the packet to control 
> plane, if it is not, it may discard the packet. 
> 
> I think the T-PE behavior is quite clear for us. If CW is supported,
> it should always check the niblle. If only CC type 3 is supported, 
> the packet with TTL=1 will be sent to control plane if it is IP packet. 
> 
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Nov 2010 09:11:00 +0200

Lizhong,
I agree that what you say is a possible interpretation of RFC 5085.
But I would like to see it explicitly specified.

And, IMO, when a PE advertizes VCCV Type 3 it advertizes its transmit capability as well as its receive capability.

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]]
Sent: Wednesday, November 17, 2010 9:06 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] VCCV usage

Hi Sasha,
>From my understanding, if VCCV Type 1 is supported without type 3 negotiated on this PW, S-PE should still always check the nibble for the TTL expiry packet. Then it will not treat it as potential IP packet. It is VCCV type 1 which enables S-PE to check the nibble.

BR
Lizhong

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Nov 2010 00:10:04 -0800

Dear Lizhong,
what would be the purpose of checking PW ACH on S-PE when only Type 1 CC was
negotiated for the given MS-PW? If I may draw parallel with G-ACh/GAL, LSR
is not checking whether there's GAL at BoS (unless TTL expired). If S-PE can
be viewed as LSR, PW segment as section, S-PE should not be checking for PW
ACH.

Regards,
Greg

On Tue, Nov 16, 2010 at 11:06 PM, <[email-masked]> wrote:

> negotiated on this PW, S-PE should still always check the nibble for the TTL
> expiry packet. Then it will not treat it as potential IP packet. It is
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: [email-masked]
Date: Wed, 17 Nov 2010 16:50:16 +0800

Hi Greg,
Of course, only when TTL expiry, S-PE will check the nibble. But we 
consider this kind of TTL expiry behavior as a standard MPLS forwarding 
behavior, not type3. S-PE will inspect any label packet if TTL is expired. 
The purpose may be PW segment monitoring, trace route, and etc.

I agree with Sasha, some clarification is necessary in RFC5085.

Lizhong

Greg Mirsky <[email-masked]> wrote on 2010-11-17 16:10:04:

> Dear Lizhong,
> what would be the purpose of checking PW ACH on S-PE when only Type 
> 1 CC was negotiated for the given MS-PW? If I may draw parallel with
> G-ACh/GAL, LSR is not checking whether there's GAL at BoS (unless 
> TTL expired). If S-PE can be viewed as LSR, PW segment as section, 
> S-PE should not be checking for PW ACH.
> 
> Regards,
> Greg

> negotiated on this PW, S-PE should still always check the nibble for
> the TTL expiry packet. Then it will not treat it as potential IP 
> packet. It is VCCV type 1 which enables S-PE to check the nibble. 
> 
> BR 
> Lizhong 
>   
> 

ZTE Information Security Notice: The information contained in this mail is solely 
property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Nov 2010 01:21:41 -0800

Dear Lizhong,
thank your for your response. Am I understanding your and Sasha's concern
with PW TTL and Type 3 CC correctly is that PW TTL can expire on S-PE even
though Type 3 CC was not negotiated?

Regards,
Greg

On Wed, Nov 17, 2010 at 12:50 AM, <[email-masked]> wrote:

> > > > Cc: "[email-masked]" <[email-masked]>, Yaakov Stein <[email-masked]
> >,

---

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

Hi Greg,
Yes, exactly. It totally depends on the source PE who sets the TTL value.

BR
Lizhong

Greg Mirsky <[email-masked]> wrote on 2010-11-17 17:21:41:

> Dear Lizhong,
> thank your for your response. Am I understanding your and Sasha's 
> concern with PW TTL and Type 3 CC correctly is that PW TTL can 
> expire on S-PE even though Type 3 CC was not negotiated? 
> 
> Regards,
> Greg
> 
> consider this kind of TTL expiry behavior as a standard MPLS 
> forwarding behavior, not type3. S-PE will inspect any label packet 
> if TTL is expired. The purpose may be PW segment monitoring, trace 
> route, and etc. 
> 

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of th
e message. Any views expressed in this message are those of the individual sender.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 17 Nov 2010 11:40:38 +0000

Wow, this has turned out to be a long and contentious thread.
Too bad we didn't discuss this issue more when we had f2f time.

I agree with Sasha that additional clarification is needed.
However, let's consider what makes sense here.

I personally think that 0001 in the first nibble after the label stack should
ALWAYS be interpreted as an associated channel packet, even if not negotiated.
After all, this nibble is registered with this meaning,
and this behavior is the norm for statically configured PWs.

TTL expiry always triggers special treatment for an IP or MPLS packet.
I think I have seen agreement here that PW TTL expiry should always trigger
a check to see if the packet is an associated channel packet
(the alternative being to discard the packet unless explicitly negotiated).
If, as Sasha suggested, the payload is "type 1" encoded,
then this check can be done unambiguously, and discarding without observing doesn't make sense.
Once again, this should happen even if type 3 was not negotiated
(what would the proper behavior be for a statically configured PW?).

How, what about type 2 ? If not negotiated, since the RA label appears above the PW label,
it is not clear that this would be properly interpreted as a PW-related indication.
So, type 2 requires negotiation.

If we deprecate type 2 (which is what I originally suggested, Luca said that he wanted to do
but didn't want to change 5085, and Sasha is pushing for now), then in fact the negotiation
of VCCV type becomes a luxury.
If the need for additional clarification triggers a respin of 5085,
then I assume that Luca will not mind deprecating.

So, I go back to my original suggestion. Both type 1 and type 3 are required to be supported,
with the usage preference being CW marking (since it helps with ECMP, ...).

TTL expiry is the only behavior when the CW is not used.
For the special case of segmental OAM for MS-PWs, there is an elegance advantage
to using TTL expiry, but I don't think that should change the default behavior.

Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, November 17, 2010 09:11
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Yaakov Stein
Subject: RE: [PWE3] VCCV usage

Lizhong,

Regards,
     Sasha

Hi Sasha,

BR
Lizhong

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Nov 2010 13:53:09 +0200

Yaakov, and all,
Please see some comments inline below.

Regards,
     Sasha

From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, November 17, 2010 1:41 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] VCCV usage

Wow, this has turned out to be a long and contentious thread.
Too bad we didn't discuss this issue more when we had f2f time.
[[[Sasha]]]  Would not help me:)... let's try to close all the issued before Prague.
I agree with Sasha that additional clarification is needed.[[[Sasha]]] Great!
However, let's consider what makes sense here.

I personally think that 0001 in the first nibble after the label stack should
ALWAYS be interpreted as an associated channel packet, even if not negotiated.
After all, this nibble is registered with this meaning,
and this behavior is the norm for statically configured PWs.
[[[Sasha]]] I do not have any objection to this (for PWs that use CW in encapsulation) when it comes to T-PE.
I do not believe that it would be right to request S-PEs to inspect the CW if the packet has not been sent to the CP by TTL expiration.
And, of course, whatever we agree upon must be explicitly specified in a Standards  Track (or BCP) RFC.

[[[Sasha]]] I am OK with that, but, again, this should be explicitly specified.

[[[Sasha]]] I do not see TTL expiry as an elegance advantage, but, rather, as the right way to do segment VCCV.
But this does not l=change the fact that, essentially, we define the same behavior 9or are very close to that).
Y(J)S

Lizhong,

Regards,
     Sasha

Hi Sasha,

BR
Lizhong

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Nov 2010 04:56:21 -0800

Dear Yaakov and All,
I think for ACH to be checked on PW without negotiating Type 1 CC we need to
extend use of GAL into MPLS-TP PWs. That is fine if we describe packet
format if Type 1 CC negotiated and there's GAL after PW label.

Regards,
Greg

On Wed, Nov 17, 2010 at 3:40 AM, Yaakov Stein <[email-masked]> wrote:

> with the usage preference being CW marking (since it helps with ECMP, …).
>
>
>
> *From:* Alexander Vainshtein [mailto:[email-masked]]
> *Sent:* Wednesday, November 17, 2010 09:11
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Yaakov Stein
>
> *Subject:* RE: [PWE3] VCCV usage
>
>
>
> Lizhong,
>
> And, IMO, when a PE advertizes VCCV Type 3 it advertizes its transmit
> capability as well as its receive capability.
>
>
>
> Regards,
>
>      Sasha
>
>
>
>
> *From:* [email-masked] [[email-masked]]
> *Sent:* Wednesday, November 17, 2010 9:06 AM
> *To:* Alexander Vainshtein
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* RE: [PWE3] VCCV usage
>
>
> Hi Sasha,

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Nov 2010 15:56:53 +0200

Greg,
As you know, both Yaakov and I have been objecting to using GAL after the PW label.
And neither do I think that GAL can be used on PWs without negotiation.
This is very different from using GAL in LSPs.

In the case of an LSP, the label immediately above GAL is associated with the action "Pop and Look further" in the ILM, while GAL is handled by virtue of adding a reserved ILM entry.

The PW label is associated with a different type of action, "Pop and forward"  to the appropriate PW Forwarder (which could be a trivial 1:1 forwarder, a VSI in the case of a PW connecting a pair of VSI of a VPLS instance etc.). Hence in order to process GAL, the PW Forwarder must be GAL-aware. This is not different from making a Forwarder VCCV Type 1-aware, so we do not gain anything, just one more VCCV Type that still makes sense only in T-PEs and does not add any functionality when it comes to those.

Regards,
     Sasha

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, November 17, 2010 2:56 PM
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] VCCV usage

Dear Yaakov and All,
I think for ACH to be checked on PW without negotiating Type 1 CC we need to extend use of GAL into MPLS-TP PWs. That is fine if we describe packet format if Type 1 CC negotiated and there's GAL after PW label.

Regards,
Greg
On Wed, Nov 17, 2010 at 3:40 AM, Yaakov Stein <[email-masked]<mailto:[email-masked]>> wrote:
Wow, this has turned out to be a long and contentious thread.
Too bad we didn't discuss this issue more when we had f2f time.

Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 17, 2010 09:11
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yaakov Stein

Lizhong,

Regards,
     Sasha

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 17, 2010 9:06 AM
To: Alexander Vainshtein
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [PWE3] VCCV usage

Hi Sasha,

BR
Lizhong

Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote on 2010-11-17 14:03:20:

> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of
> [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> >    <[email-masked]<mailto:[email-masked]>>
> > To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "Bocci,
> >    Matthew   (Matthew)" <[email-masked]<mailto:[email-masked]>>
> > Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Yaakov Stein <[email-masked]<mailto:[email-masked]>>,
> >    "Luca Martini \(lmartini\)" <[email-masked]<mailto:[email-masked]>>
> > Message-ID:
> > alcatel-lucent.com<http://alcatel-lucent.com>>
> >

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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Nov 2010 06:08:34 -0800

Dear Sasha,
you might recall that I'm not supporter of that, extending LAG into MPLS-TP
PW, idea either. I've just wanted to illustrate that proposal to require PW
always aware of 0001b frist nibble, in my view, equates to extending LAG.
Before IETF-79 I've commented to the proposal to update RFC 5586 and extend
LAG into MPLS-TP PW that it will create anothe CC type that needs
negotiation. I was not at the meeting and waiting to read the minutes to
learn if there was a discussion and what is the course after the draft
became PWE3 WG document.

Regards,
Greg

On Wed, Nov 17, 2010 at 5:56 AM, Alexander Vainshtein <
[email-masked]> wrote:

> In the case of an LSP, the label immediately above GAL is associated with
> the action “Pop and Look further” in the ILM, while GAL is handled by virtue
> of adding a reserved ILM entry.
>
>
>
> The PW label is associated with a different type of action, “Pop and
> forward”  to the appropriate PW Forwarder (which could be a trivial 1:1
> forwarder, a VSI in the case of a PW connecting a pair of VSI of a VPLS
> instance etc.). Hence in order to process GAL, the PW Forwarder must be
> GAL-aware. This is not different from making a Forwarder VCCV Type 1-aware,
> so we do not gain anything, just one more VCCV Type that still makes sense
> only in T-PEs and does not add any functionality when it comes to those.
>
>
>
> Regards,
>
>      Sasha
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, November 17, 2010 2:56 PM
> *To:* Yaakov Stein
> *Cc:* Alexander Vainshtein; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
>
> *Subject:* Re: [PWE3] VCCV usage
>
>
>
> Dear Yaakov and All,
>
> I think for ACH to be checked on PW without negotiating Type 1 CC we need
> to extend use of GAL into MPLS-TP PWs. That is fine if we describe packet

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Nov 2010 15:27:54 +0000

> And neither do I think that GAL can be used on PWs without negotiation.
I would not be averse to saying that the use of GAL should be 
negotiated, but it is not required by the MPLS architecture.

The GAL is a reserved label, so the LSE parser should find it and punt 
the packet to the reserved label handler. However the PW should also 
co-ordinate the VCCV type between the two ends and thus GAL would become 
VCCV type 4.

Stewart (speaking as Stewart)

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Nov 2010 18:36:12 +0200

Stewart,
IMHO we have already interoperability problems with 3 VCCV types.
adding one more does not help.
regards,
     Sasha
________________________________________
From: Stewart Bryant [[email-masked]]
Sent: Wednesday, November 17, 2010 5:27 PM
To: Alexander Vainshtein
Cc: Greg Mirsky; [email-masked]; Yaakov Stein; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] VCCV usage

---

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

Hi Sasha,

Right. The capability advertisement is not only a capability to
intercept (which is a bit implicit for Type 3) but also a capability to
further process given CV Types.

Thanks,

-- Carlos.

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Wednesday, November 17, 2010 1:03 AM
To: [email-masked]; [email-masked]
Cc: Carlos Pignataro (cpignata); [email-masked]; [email-masked]; Luca
Martini (lmartini)
Subject: RE: [PWE3] VCCV usage

Hi all,

It seems that I have been wrong when I have said that combining VCCV
Type 1 and VCCV Type 3 requires only some transmit capabilities. VCCV
Type 1 indeed means that T-PE always examines the first nibble of the CW
on receive. 

At the same time I think that VCCV Type 3 in the presence of CW still
has to be negotiated.

Otherwise the CP that intercepts a VCCV packet due to TTL expiration
could possibly treat it as a potential IP packet, find an invalid IP
header and discard the packet as an error.  So advertizing VCCV Type 3
for a PW that uses CW means that first nibble set to 0b0001 would be
considered as valid, and the packet would be further processed based on
the ACH type in the PW-ACH header.

Regards,

     Sasha

Cc: [email-masked]; [email-masked]; [email-masked];

Hi all, 
I agree with Mustapha's statement about TTL expiry for S-PE. 
For MS-PW, IMO, CC type 1 MUST be deployed and negotiated in order to
avoid leaking packets to AC, and CC Type 3 is not necessary to be
negotiated. 
The S-PE behavior is like below: 
When S-PE receives packets with TTL=1, it should check whether this PW
support CW, if it does, it will check the nibble. If the packets are
data packets, it may discard the packets. If it is control packet, send
it to control plane. 
If this PW does not support CW, then it check if CC type 3 is supported
by this PW. If CC type 3 is supported, S-PE should check if the packet
is IP packet, if it is, send the packet to control plane, if it is not,
it may discard the packet. 

I think the T-PE behavior is quite clear for us. If CW is supported, it
should always check the niblle. If only CC type 3 is supported, the
packet with TTL=1 will be sent to control plane if it is IP packet. 

Lizhong

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

---

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

Yaakov,

Please find one or two comments inline.

> and this behavior is the norm for statically configured PWs.

I agree.

> (what would the proper behavior be for a statically configured PW?).

I also agree.

The question in these two cases however becomes: Can a source PE send
these packets to a target PE even when did not receive capability
support from that target PE?

Wouldn't this require negotiation (or otherwise would intercept and just
drop, if using TTL crafting only)?

> So, type 2 requires negotiation.

I missed this part, why does this require negotiation? It is from RFC 3032.

> of VCCV type becomes a luxury.

Did this logic skipped Type 1, i.e., intercepting based on the first
nibble? That is different than, once intercepted, then check the first
nibble.

Thanks,

-- Carlos.

> ------------------------------------------------------------------------
> 
> TTL expiry packet. Then it will not treat it as potential IP packet. It
> is VCCV type 1 which enables S-PE to check the nibble.
> 
> BR
> Lizhong
>  
> 
> ------------------------------------------------------------------------
>

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Dec 2010 06:49:26 +0000

Carlos

Sorry that it took me a bit of time to catch up on PWE emails.

I don't think it would be useful for me to try to answer old questions,
as the water has already reached the sea.
However, there is one point I wanted to comment on.

[YJS] So, type 2 requires negotiation.
[Carlos]  I missed this part, why does this require negotiation? It is from RFC 3032.

I completely agree that an LSR recognizes the router alert label.
However, there are many situations where the PW interworking is not performed by 
a device with full MPLS functionality.
For example, consider a PW setup with only the PW label over IP according to RFC 4023.

Here the receiving device would be quite surprised to find the router alert label,
were it not informed that this is a possibility.

Y(J)S

---

From: <[email-masked]>
Date: Wed, 1 Dec 2010 07:48:27 +0000

Hi Yaakov...you may like to ponder on this point (I have raised it several times before, but for some reason it gets ignored...I wonder why? ;-)) ....

Any layer network SHOULD (though this really ought to be MUST) have consistent CI (Characteristic Information).  There are many reasons for this rather obvious requirement statement, but a key one is that if misconnectivity occurs, then wherever the misdirected DP traffic units and OAM arrive they can be correctly processed...this means that all the functional fields of DP traffic units and DP OAM MUST have unambiguous functional meaning.  I think this statement is so obviously true that no sane person could disagree with it.

Aside=> The above requirement is true for all 3 network modes, but it is most important in a co-ps mode network (as this has the richest potential set of misconnectivity defects) where short-cuts have been taken on child traffic unit labelling (ie omit SA label, DA label reduced to link significant, omit PID label) due to the a-priori-known single-source property of the parent connection.  However, this a-priori-known single-source property of a parent connection is broken under misconnectivity defects and cannot, indeed MUST NOT, be assumed...ergo why child traffic units and OAM MUST have consistent CI.

You are raising one case below where there is non-consistent CI.....but there are many more.  Even the 'label' (there is only one) in an MPLS traffic unit is not consistent of its meaning.  Then we have lots of choices for OAM.  Now factor-in mixed cases of LSP sublayering and LSP layering...the former LSPs reside in the *same layer network* whilst the latter LSPs reside in *different layer networks* (this is a rather more serious self-inflicted consequential problem BTW).

Do you think it is sensible given the above is 'known' (and for some time) that such mistakes should be carried over into MPLS-TP?....esp given this is supposed to be a transparent transport network (hint=> this should never have sublayering and esp not PWs as all clients MUST be treated equally...else we do not have a transparent transport network).

Please excuse me copying this to the MPLS-TP list as my observation is clearly germane to that WG too.

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: 01 December 2010 06:49
> To: Carlos Pignataro
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> I don't think it would be useful for me to try to answer old 
> questions, as the water has already reached the sea.
> However, there are many situations where the PW interworking 
> is not performed by a device with full MPLS functionality.
> Here the receiving device would be quite surprised to find 
> the router alert label, were it not informed that this is a 
> possibility.
> 
> Y(J)S
> 
>