Subject: Re: [PWE3] VCCV usage

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 2 Dec 2010 20:50:42 -0600

Yaakov,

Thank you for the follow-up.

I do not agree that a device implementing RFC 4023 (or RFC 4817) would be except from understanding MPLS. These are encapsulations of MPLS. A device being surprised to see a RA label here would be non-compliant, and RA is not a possibility but a support requirement.

Specifically, http://tools.ietf.org/html/rfc4023#section-3 says:

         MPLS Label Stack
             This field contains an MPLS Label Stack as defined in
             [RFC3032].
...
   Following the IP header is an MPLS packet, as specified in [RFC3032].

And an MPLS LSE as defined by RFC 3032 includes the "Router Alert Label".

Same for http://tools.ietf.org/html/rfc4817#section-2.

I think that there are no support differences for MPLS coming in an IP tunnel or an Ethernet interface.

Going back to the original question: Why would Type 2 require negotiation?

Thanks,

-- Carlos.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 1:49 AM
To: Carlos Pignataro (cpignata)
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]; Luca Martini (lmartini)
Subject: RE: [PWE3] VCCV usage

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: Yaakov Stein <[email-masked]>
Date: Fri, 10 Dec 2010 09:20:37 +0000

Carlos

Yes, 4023 definitely states that there is a label STACK,
and the packet FORMAT complies with that of MPLS.
It does not say that there needs to be MPLS PROCESSING.

That is why Type 2 needs negotiation.

Y(J)S

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Friday, December 03, 2010 04:51
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]; Luca Martini (lmartini)
Subject: RE: [PWE3] VCCV usage

Yaakov,

         MPLS Label Stack

Thanks,

-- Carlos.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 1:49 AM
To: Carlos Pignataro (cpignata)
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]; Luca Martini (lmartini)
Subject: RE: [PWE3] VCCV usage

Carlos

	

Y(J)S

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 10 Dec 2010 06:20:25 -0600

Yaakov,

I disagree. I think that just by reading the first section of RFC 4023, " Motivation", <http://tools.ietf.org/html/rfc4023#section-1>, it is clear that there is MPLS PROCESSING.

It starts like this:

1.  Motivation

   In many applications of MPLS, packets traversing an MPLS backbone
   carry label stacks with more than one label.  As described in section
   3.15 of [RFC3031], each label represents a Label Switched Path (LSP).

CMP: So this is based on the stack where each LSP (e.g., the inner label)
CMP: corresponds to an LSP from the MPLS ARCHITECTURE [RFC3031].

   For each LSP, there is a Label Switching Router (LSR) that is the
   "LSP Ingress", and an LSR that is the "LSP Egress".  If LSRs A and B
   are the Ingress and Egress, respectively, of the LSP corresponding to
   a packet's top label, then A and B are adjacent LSRs on the LSP
   corresponding to the packet's second label (i.e., the label
   immediately beneath the top label).

CMP: The "LSP Egress", LSR, and adjacent LSRs are terms from this MPLS
CMP: Architecture. This explicitly says how there is an LSR 
CMP: Adjacency for the 2nd label.

   The purpose (or one of the purposes) of the top label is to get the
   packet delivered from A to B, so that B can further process the
   packet based on the second label.  In this sense, the top label

CMP: Here it even says "can further PROCESS the packet based on the
CMP: second label".

Thanks,

-- Carlos.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Friday, December 10, 2010 4:21 AM
To: Carlos Pignataro (cpignata)
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]; Luca Martini (lmartini)
Subject: RE: [PWE3] VCCV usage

Carlos

Y(J)S

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Friday, December 03, 2010 04:51
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]; Luca Martini (lmartini)
Subject: RE: [PWE3] VCCV usage

Yaakov,

         MPLS Label Stack
..

Thanks,

-- Carlos.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 1:49 AM
To: Carlos Pignataro (cpignata)
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]; Luca Martini (lmartini)
Subject: RE: [PWE3] VCCV usage

Carlos

	

Y(J)S

---

From: IETF <[email-masked]>
Date: Fri, 10 Dec 2010 08:09:49 -0800

I agree with Carlos.
Type 2 need not be negotiated. If packet is received with RA and the device cannot process, then it is not fully compliant. That is how I read rfc4023.

Cheers
Sam

Sent from my iPhone

On Dec 10, 2010, at 4:20 AM, "Carlos Pignataro (cpignata)" <[email-masked]> wrote:

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

---

From: [email-masked]
Date: Sun, 12 Dec 2010 10:54:45 +0800

Hi Carlos,
The rule you are describing in RFC4023 is only applied for label from 
16~(2^20-1). And RA is an exception label, you can not rely on the content 
of RA to do further MPLS process. The only processing behavior indicated 
by RA is to do an exception for control plane processing.

BR
Lizhong

"Carlos Pignataro (cpignata)" <[email-masked]> wrote on 2010-12-10 
20:20:25:

> Yaakov,
> 
> I disagree. I think that just by reading the first section of RFC 
> 4023, " Motivation", <http://tools.ietf.org/html/rfc4023#section-1>,
> it is clear that there is MPLS PROCESSING.
> 
> It starts like this:
> 
> 1.  Motivation
> 
> Cc: Alexander Vainshtein; [email-masked]; mustapha.
> [email-masked]; [email-masked]; Luca Martini (lmartini)
> Cc: Alexander Vainshtein; [email-masked]; mustapha.
> [email-masked]; [email-masked]; Luca Martini (lmartini)
> I do not agree that a device implementing RFC 4023 (or RFC 4817) 
> would be except from understanding MPLS. These are encapsulations of
> MPLS. A device being surprised to see a RA label here would be non-
> compliant, and RA is not a possibility but a support requirement.
> 
> Cc: Alexander Vainshtein; [email-masked]; mustapha.
> [email-masked]; [email-masked]; Luca Martini (lmartini)

--------------------------------------------------------
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 (cpignata)" <[email-masked]>
Date: Sat, 11 Dec 2010 22:22:07 -0500

Hi Lizhong,

Please see inline. 

Thumb typed by Carlos Pignataro.

On Dec 11, 2010, at 9:56 PM, "[email-masked]" <[email-masked]> wrote:

> 
> Hi Carlos, 
> The rule you are describing in RFC4023 is only applied for label from 16~(2^20-1).

Where does it say that? RFC 3031 and RFC 3032 normatively referenced apply to the full label space.
... This would mean that Explicit-null cannot be used, and Imp-null not signaled here?

> And RA is an exception label, you can not rely on the content of RA to do further MPLS process. The only processing behavior indicated by RA is to do an exception for control plane processing. 

There is no "content" of the RA. With a label with value, the packet is delivered to local software for processing, with processing context based on the label underneath. 

Thanks,

Carlos. 

> 
> BR 
> Lizhong 
>   
> 
> "Carlos Pignataro (cpignata)" <[email-masked]> wrote on 2010-12-10 20:20:25:
> 
> > Yaakov,
> >

---

From: IETF <[email-masked]>
Date: Sat, 11 Dec 2010 19:57:39 -0800

Comment online.

Sent from my iPhone

> The rule you are describing in RFC4023 is only applied for label from 16~(2^20-1).
%sam- does that mean it is not applicable to explicit label?
The processing is applied here based on the top label.

Cheers
Sam

---

From: [email-masked]
Date: Mon, 13 Dec 2010 08:58:48 +0800

Hi Carlos,
The processing context of label underneath is pseudowire label, and 
normally the PW label only tells you to forward the packet to a specified 
AC. The type2 negotiation result just tells control plane to look up the 
packet based on the format of CV type, instead of forwarding to AC.

Regards
Lizhong

"Carlos Pignataro (cpignata)" <[email-masked]> wrote on 2010-12-12 
11:22:07:

> On Dec 11, 2010, at 9:56 PM, "[email-masked]" 
<[email-masked]
> > wrote:

> And RA is an exception label, you can not rely on the content of RA 
> to do further MPLS process. The only processing behavior indicated 
> There is no "content" of the RA. With a label with value, the packet
> is delivered to local software for processing, with processing 
> context based on the label underneath. 
> 
> Thanks,
> 
> Carlos. 
> 
> 
> 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.
> 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: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 21 Dec 2010 13:04:04 -0600

Hi Lizhong,

Apologies for the delay. What you describe about the processing is
correct, if there is no "examine more closely" semantics. But the RA
label adds the "examine more closely" instead of just forward out.

Thanks,

-- Carlos.

From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, December 12, 2010 7:59 PM
To: Carlos Pignataro (cpignata)
Cc: Alexander Vainshtein; Luca Martini (lmartini);
[email-masked]; [email-masked]; Yaakov Stein
Subject: Re: [PWE3] VCCV usage

Hi Carlos, 
The processing context of label underneath is pseudowire label, and
normally the PW label only tells you to forward the packet to a
specified AC. The type2 negotiation result just tells control plane to
look up the packet based on the format of CV type, instead of forwarding
to AC. 

Regards 
Lizhong 

<[email-masked]

--------------------------------------------------------
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: [email-masked]
Date: Thu, 23 Dec 2010 11:23:13 +0800

Hi Carlos,
Maybe I've got your meaning. Then if it can be ensured that there is only 
one CC type for this PW, and the CC type is RA, then RA does not need to 
be negotiated. But what if RA is a default supporting CC type, it is 
possible the operator configures another CC type (e.g, control word), then 
the PW will support two CC type which is not allowed actually (because you 
can not examine the packet based on CW or Raw IP). What's more, if there 
is no RA negotiation in MS-PW (actually, T-PE have not the knownledge of 
MS-PW or SS-PW), it may lead the MS-PW to support RA by default.

Regards
Lizhong

"Carlos Pignataro (cpignata)" <[email-masked]> wrote on 2010-12-22 
03:04:04:

> correct, if there is no “examine more closely” semantics. But the RA
> label adds the “examine more closely” instead of just forward out.
> 
> Thanks,
> 
> -- Carlos.
> 
> Cc: Alexander Vainshtein; Luca Martini (lmartini); mustapha.
> [email-masked]; [email-masked]; Yaakov Stein
> specified AC. The type2 negotiation result just tells control plane 
> to look up the packet based on the format of CV type, instead of 
> forwarding to AC. 
> 
> Regards 
> Lizhong 
> 
> 
> "Carlos Pignataro (cpignata)" <[email-masked]> wrote on 
> 2010-12-12 11:22:07:
> 
> > Hi Lizhong, 
> > 
> > Please see inline. 
> > 
> > On Dec 11, 2010, at 9:56 PM, "[email-masked]" <lizhong.
> [email-masked]
> > > wrote:
> 
> > 
> > Hi Carlos,

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 23 Dec 2010 08:10:11 -0800

Hi Lizhong,

Please find comments inline.

Sent from my iPhone

On Dec 22, 2010, at 7:23 PM, [email-masked] wrote:

> 
> Hi Carlos, 
> Maybe I've got your meaning. Then if it can be ensured that there is only one CC type for this PW, and the CC type is RA, then RA does not need to be negotiated. But what if RA is a default supporting CC type, it is possible the operator configures another CC type (e.g, control word), then the PW will support two CC type which is not allowed actually (because you can not examine the packet based on CW or Raw IP).
Why is support of two cc types wrong. You could support both cc types, but when you encapsulate the packet you choose one over the other.
> What's more, if there is no RA negotiation in MS-PW (actually, T-PE have not the knownledge of MS-PW or SS-PW), it may lead the MS-PW to support RA by default. 
Again, it doesn't matter RA is supported or not. RA has the least priority while encapsulating the pong packet.
If another cc type is supported they get the preference over RA.
If RA is present, you cannot use beyond one segment, that is one of the reasons for having low priority to this cc type, doesn't mean it should not be there.
Useful cc type for ss-pw.

-sam

> 
> Regards 
> Lizhong 
> 
> 
> "Carlos Pignataro (cpignata)" <[email-masked]> wrote on 2010-12-22 03:04:04:
> 
> > Hi Lizhong, 
> >   
> > > 2010-12-10 20:20:25:

---

From: [email-masked]
Date: Fri, 24 Dec 2010 00:54:15 +0800

Hi Sam,
Sorry for some misunderstanding words. See in line below.

Lizhong

> Maybe I've got your meaning. Then if it can be ensured that there is
> only one CC type for this PW, and the CC type is RA, then RA does 
> not need to be negotiated. But what if RA is a default supporting CC
> type, it is possible the operator configures another CC type (e.g, 
> control word), then the PW will support two CC type which is not 
> allowed actually (because you can not examine the packet based on CW
> or Raw IP). 
> Why is support of two cc types wrong. You could support both cc 
> types, but when you encapsulate the packet you choose one over the 
other.
[Lizhong] sorry, my wrong words, I mean only one CC type can be choosen 
for PW. The example above is not right actually, sorry.

> What's more, if there is no RA negotiation in MS-PW (actually, T-PE 
> have not the knownledge of MS-PW or SS-PW), it may lead the MS-PW to
> support RA by default. 
> Again, it doesn't matter RA is supported or not. RA has the least 
> priority while encapsulating the pong packet.
[Lizhong] what is "pong" packet? RA is type2 and TTL==1 as type3 has least 
priority.

> If RA is present, you cannot use beyond one segment, that is one of 
> the reasons for having low priority to this cc type, doesn't mean it
> should not be there.
[Lizhong] I try to say CC type RA negotiation is necessary for PW, not say 
RA is supported or not. When CC type2 RA negotiation is applied, we can 
ensure that CC type for MS-PW will not be RA type2, because S-PE will 
reset the CC type2 during negotiation.

> 2010-12-22 03:04:04:
> > > > 4023, " Motivation", 
<http://tools.ietf.org/html/rfc4023#section-1>,
> > > > I think that there are no support differences for MPLS coming in 
an 
> > > > IP tunnel or an Ethernet interface.
> > > > 
> > > > [Carlos]  I missed this part, why does this require negotiation? 
It 
> > > > is from RFC 3032.
> > > > However, there are many situations where the PW interworking is 
not 
> > > > performed by 

system.

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 23 Dec 2010 09:13:13 -0800

Hi Lizhong,

Comments inline.

Sent from my iPhone

On Dec 23, 2010, at 8:54 AM, [email-masked] wrote:

> > types, but when you encapsulate the packet you choose one over the other. 
> [Lizhong] sorry, my wrong words, I mean only one CC type can be choosen for PW. The example above is not right actually, sorry. 
> 
> [Lizhong] what is "pong" packet?
Typo. It should be ping pkt.
> RA is type2 and TTL==1 as type3 has least priority.
Why is type 3 least priority? Could you explain?
> [Lizhong] I try to say CC type RA negotiation is necessary for PW, not say RA is supported or not. When CC type2 RA negotiation is applied, we can ensure that CC type for MS-PW will not be RA type2, because S-PE will reset the CC type2 during negotiation. 
Not true. If you have to perform operation which spans across segments, one cannot use type2 at all.
So, whether you negotiate or not is irrelevant.
Even if RA support(type2) is present, you cannot use it for Mspw.
Could you give a case scenario where you'd be forced to use type2 in Mspw scenario?

Sam

---

From: [email-masked]
Date: Fri, 24 Dec 2010 01:25:26 +0800

Sam, see in line please.

Regards
Lizhong

other. 
> [Lizhong] sorry, my wrong words, I mean only one CC type can be 
> choosen for PW. The example above is not right actually, sorry. 
> 
[Lizhong] RFC5085 section 7 describes the precedence.

> [Lizhong] I try to say CC type RA negotiation is necessary for PW, 
> not say RA is supported or not. When CC type2 RA negotiation is 
> applied, we can ensure that CC type for MS-PW will not be RA type2, 
> because S-PE will reset the CC type2 during negotiation. 
[Lizhong] According to the precedence, TTL==1 has least priority, then it 
is possible for T-PE to choose type2 (higher precedence that type3) for 
MS-PW if there is no type2 negotiation in VCCV, not type3, for the case of 
only TTL==1 is possibly supported for MS-PW.

> > > > Where does it say that? RFC 3031 and RFC 3032 normatively 
referenced
> > > > apply to the full label space. 
> > > > ... This would mean that Explicit-null cannot be used, and 
Imp-null 
> > > > not signaled here? 

> > > > > CMP: The "LSP Egress", LSR, and adjacent LSRs are terms fromthis 
MPLS

an 
> > > > > I don't think it would be useful for me to try to answer 
oldquestions,
It 
not 
system.
system.

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 23 Dec 2010 09:45:42 -0800

Inline for my comment.

Sent from my iPhone

On Dec 23, 2010, at 9:25 AM, [email-masked] wrote:

> [Lizhong] According to the precedence, TTL==1 has least priority, then it is possible for T-PE to choose type2 (higher precedence that type3) for MS-PW if there is no type2 negotiation in VCCV, not type3, for the case of only TTL==1 is possibly supported for MS-PW. 
Vccv rfc was written when there was no concept of Mspw.
My point is even if RA is supported type, one cannot use it to encapsulate the packet, if it is being sent to segment which is beyond one segment I.e when pw label ttl>1.
But one could use RA to force pkt processed at next segment hop even if type2 is not negotiated type, which in my opinion is very useful option to have.

Sam

> > > > > > CMP: The "LSP Egress", LSR, and adjacent LSRs are terms fromthis MPLS
> > > > > > I don't think it would be useful for me to try to answer oldquestions,