Subject: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 12 Nov 2009 10:51:57 +0100

Steward,

Had a few question/clarification on the following draft:
draft-bryant-pwe3-packet-pw-02.txt

1.	As discussed we could also have LER functionality besides LSR.
It would be good to clarify the encapsulation which would be used for
IP-VPN or PW services using the packet PW service. Do we use 2 MPLS
labels (service and transport)
2.	Is my understanding correct that for each protocol type we need
to signal a different label? Meaning IP services get a label X, MPLS
services get label Y, etc
		In essence I get a different label for each protocol
type I transport over this PW?
		If this is correct why do I not use a standard ETH PW
for this since it has all these capabilities already.

		Cheers,
		Wim

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Nov 2009 15:42:21 +0000

HENDERICKX Wim wrote:
> IP-VPN or PW services using the packet PW service.
>
We will add the clarification
>
> Do we use 2 MPLS labels (service and transport)
>
The inner labels presented from the embedded client router are exactly 
the same as the would be if the packet was going over a real data link 
over a physical wire. Instead of using a real data link we use a label 
to represent the PID in the datalink, and the use the PW in place of the 
physical wire.

> 2.      Is my understanding correct that for each protocol type we 
> need to signal a different label? Meaning IP services get a label X, 
> MPLS services get label Y, etc
>
>             In essence I get a different label for each protocol type
>             I transport over this PW?
>
Yes
>
>             If this is correct why do I not use a standard ETH PW for
>             this since it has all these capabilities already.
>
Three reasons:

1) We need 4 bytes instead of 14 bytes
2) A pt-pt link has lower adjacency formation overhead
3) This is more consistent with RFC3031 which says that the protocol 
after the label with the S bit is learned from the context provided by 
the label with the S bit. This was one of the areas that caused 
significant discussion in the MPLS-TP client design, and although pkt 
-PW is part of mainstream PWE3 rather than MPLS-TP it is good to be 
consistent.

If a vendor wished to deliver this service via a virtual Ethernet they 
can, and no protocol specifications are required beyond those that 
already exist in PWE3.

- Stewart

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

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Sat, 14 Nov 2009 15:00:31 +0100

Stewart, more in-line indicated with WH>

________________________________

From: Stewart Bryant [mailto:[email-masked]] 
Sent: donderdag 12 november 2009 16:42
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

HENDERICKX Wim wrote: 

Steward,

WH> if we have multiple client services e.g. multiple LSR LSPs to
different destinations how would they be distinguished in the case of
the pkt-PW ?

In essence I get a different label for each protocol type I transport
over this PW?

Yes

If this is correct why do I not use a standard ETH PW for this since it
has all these capabilities already.

Three reasons:

WH> right but we need to signal more PID labels, one per protocol type

WH> I believe that for IGPs and MPLS links there are options for P2P
support on ETH which would be the same.

WH> understood

WH> We might want to clarify the above in the draft

- Stewart

Cheers,

Wim

________________________________

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 14 Nov 2009 17:16:02 +0000

HENDERICKX Wim wrote:
> *From:* Stewart Bryant [mailto:[email-masked]]
> *Sent:* donderdag 12 november 2009 16:42
> *To:* HENDERICKX Wim
> *Cc:* [email-masked]
> *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
>
>  
>
> HENDERICKX Wim wrote:
>
> Steward,
>
> to represent the PID in the datalink, and the use the PW in place of 
> the physical wire.
>
SB> The ingress PE needs a PW to each egress PE that they have client 
traffic for. It is up to the embedded client router to select the 
correct pkt PW, i.e. the one that terminates on the egress PE that hosts 
the embedded client router that is the next hop in the client layer.

> If this is correct why do I not use a standard ETH PW for this since 
> it has all these capabilities already.
>
> Three reasons:
>
SB> Sure, but that is a control plane action.
> support on ETH which would be the same.
SB> Yes, though there are some sublties. You still need to used ARP and 
the Multicast addresses.
> [email-masked] <mailto:[email-masked]>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Sat, 14 Nov 2009 18:25:15 +0100

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: zaterdag 14 november 2009 18:16
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

WH> what I meant is this:

            --------                       --------
   PE1-----|        |                     |        | --- PE3
           |  LSR   |------- PKT PW ------|  LSR   |
           |        |                     |        |
   PE2-----|        |                     |        |---- PE4
            --------                       --------

Assume PE1 has a LSP to PE3 and PE2 has an LSP to PE4, how is this
distinguished on the PKT PW ?

WH> but the data-plane needs also the label per protocol type unless we
make them static.

WH> this is correct

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Nov 2009 13:28:11 +0000

>> Stewart, more in-line indicated with WH>
SB> I am not sure what you have drawn there, but it is not what is shown 
in  the draft. The pkt pw run between the PEs and is carried over the 
LSPs. PWs are distinguished from each other at the PE via the PW label.

> WH> but the data-plane needs also the label per protocol type unless we
SB> I don't understand what you are saying here. This is normal MPLS. 
You decide on a mapping between a label value and  a context, and signal 
that mapping to your peer, who programs their hardware accordingly. 
There is no need for static labels.

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 16 Nov 2009 14:36:19 +0100

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: maandag 16 november 2009 14:28
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

WH> What I tried to draw is PE(s) attached to the device (drawn with the
box) which is performing the LSR function on a PKT PW to another device
(drawn with the box) which attaching PE(s).

The question is if I have multiple LSPs from different PE(s) through the
PKT PW how are the distinguished. Do I need a separate PID LBL, a
separate PW, etc such that the LSR can make the correct LBL mappings.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Nov 2009 13:49:27 +0000

Wim

Think of the PW as a point to point link between a pair of PEs. The PE 
chooses what traffic to sent over a given PW. The PE then pushes an MPLS 
label to identify the destination. The mid-point LSRs have no clue what 
is being carried over the LSP. The egress PE unwraps that packet and 
figures out what the payload is.

RFC3985 applies to pkt pw as it does to any other PW.

- Stewart

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 16 Nov 2009 15:03:23 +0100

Ok good, this is what I thought, the client LSP exist in the "client
packet Network layer". 

Don't you think this is a huge stack for such a function. You could have
4-6 LBL(s) + CW (optionally). I understand this proposal re-uses
existing functions defined in MPLS, but there are lot's of optimizations
possible here -> we could combine FAT LBL, PID LBL, CW potentially.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: maandag 16 november 2009 14:49
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

Wim

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 16 Nov 2009 09:38:34 -0500

Wim,

It's still more efficient on the wire than a simulated Ethernet PW,
because you would have one less label (the protocol identifier), but
would add the Ethernet MAC header instead.

Cheers,
Andy

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 16 Nov 2009 17:52:07 +0100

This is correct but could we not optimize this special mapping ?

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]] 
Sent: maandag 16 november 2009 15:39
To: HENDERICKX Wim
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

Wim,

Cheers,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Nov 2009 17:14:35 +0000

It depends what you mean by optimize.

Say you have 100 PWs and 2 protocols

If you optimize for minimum number of unique labels by separating the 
functions, as per the draft, this takes 102 labels

If you optimize for number of labels in the stack, which is what you are 
requesting, you need 200 unique labels.

- Stewart

HENDERICKX Wim wrote:
>>> SB> I am not sure what you have drawn there, but it is not what is
>>>       
>> shown
>>     
>>> LSPs. PWs are distinguished from each other at the PE via the PW
>>>       
>> label.
>>     
>>> WH> What I tried to draw is PE(s) attached to the device (drawn with
>>>       
>> the
>>     
>>> box) which is performing the LSR function on a PKT PW to another
>>>       
>> device
>>     
>>> The question is if I have multiple LSPs from different PE(s) through
>>>       
>> the
>>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 16 Nov 2009 20:56:25 +0100

I would vote for the latter. It is not much about the label uniqueness
but the depth of the stack since it reduces BW.

If we embed the e-type in the label it becomes more easy as well.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: maandag 16 november 2009 18:15
To: HENDERICKX Wim
Cc: Andrew G. Malis; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Nov 2009 20:08:20 +0000

The amount of b/w that you save is completely trivial.

- Stewart

HENDERICKX Wim wrote:
>>> Don't you think this is a huge stack for such a function. You could
>>>       
> have
>   
>>> existing functions defined in MPLS, but there are lot's of
>>>       
> optimizations
>   
>>>> in  the draft. The pkt pw run between the PEs and is carried over
>>>>         
> the
>   
>>>> separate PW, etc such that the LSR can make the correct LBL
>>>>         
> mappings.
>   
>>>>       
>>>>         
>>> Wim
>>>
>>> Think of the PW as a point to point link between a pair of PEs. The
>>>       
> PE
>   
>>> chooses what traffic to sent over a given PW. The PE then pushes an
>>>       
> MPLS
>   
>>> label to identify the destination. The mid-point LSRs have no clue
>>>       
> what
>

---

From: [email-masked]
Date: Tue, 17 Nov 2009 14:20:39 +0800

I see this as an experiment to design a pure MPLS transport technology 
avoid of Ethernet and other L2 encapsulation.

Now it is in virtual world, but targets at real world.

"Andrew G. Malis" <[email-masked]> 
发件人:  [email-masked]
2009-11-16 22:38

收件人
HENDERICKX Wim <[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

Wim,

Cheers,
Andy

--------------------------------------------------------
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: Tue, 17 Nov 2009 09:56:17 -0000

I'm finding this discussion somewhat bizarre.  How can any discussion of MPLS efficiency ignore the fact that MPLS cannot 'put bits on the wire'?  This also relates to the MPLS-TP discussion, ie MPLS-TP is claimed to be a *transport*  technology.....but how one one say this with a straight face when it would have to run over a real transport network that has a physical layer specification (ie binary=>q'ary symbol lexicon mapping) that can modulate an EM wave in metallic/optical/radio media?
 
SDH and OTN obviously have physical layer specifications, but so has Ethernet...indeed it has a very rich support for all types of metallic/optical/radio media.  Which is of course why MPLS often runs over Ethernet...and which then begs the rather obvious question that if one simply wants a transport network, then why not use Ethernet per se?
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 17 November 2009 06:21
	To: Andrew G. Malis
	Cc: [email-masked]; HENDERICKX Wim; [email-masked]; [email-masked]
	Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

	I see this as an experiment to design a pure MPLS transport technology avoid of Ethernet and other L2 encapsulation. 

	

	

2009-11-16 22:38 

收件人

	Wim,

	Cheers,
	Andy

---

From: David Allan I <[email-masked]>
Date: Tue, 17 Nov 2009 08:28:21 -0500

It is a bit counter intuitive to me that the technology that added Penultimate Hop Popping to our venacular as an optimization in minimizing the required egress packet fondling, is now bracing for having to process a plethora of labels... 

A variation on the "what Grove giveth, Gates taketh away" theme??

Cheers
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, November 16, 2009 3:08 PM
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

- Stewart

HENDERICKX Wim wrote:
>>>> WH> What I tried to draw is PE(s) attached to the device (drawn 
>>>> WH> with
>>>>       
>>>>         
>>> the
>>>     
>>>

---

From: Luca Martini <[email-masked]>
Date: Wed, 18 Nov 2009 15:18:02 -0700

Wim,

We can , of course , always reduce the label stack depth by merging 
labels, but that is usually not a good idea , as it will increase the 
number of labels, that that is the most expensive part of MPLS.
Also note that The FAT PW would not be very useful with a packet PW that 
contains IP.
Let assume for a moment that 99.9% of traffic in a packet PW will be IP 
... ( most likely it's much higher then that )
I do not like the CW much , so let say that we simply encapsulate the IP 
packet into a protocol label, a PW label, and a tunnel label.
That's a 3 label stack , with excellent load sharing capabilities. If 
you pull the PID out into a CW , for example , you will have to add 
another label , and also make the encapsulation process much more 
complicated at the PE.
So , for this application it's better to just have 3 labels.

Luca

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 19 Nov 2009 09:22:50 +0100

Luca, for IP you are right in terms of protocol stack but I have the
impression that the packet-PW draft is more generic and we should be
open minded to other applications apart from IP.

What I propose is to have 1. tunnel label - 2. pw label - 3. a label
which combines the pid label + CW + hash label.

-----Original Message-----
From: Luca Martini [mailto:[email-masked]] 
Sent: woensdag 18 november 2009 23:18
To: HENDERICKX Wim
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

Wim,

contains IP.

Luca

>>>> WH> What I tried to draw is PE(s) attached to the device (drawn
with

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 19 Nov 2009 06:26:34 -0500

Wim,

What procedures would you use to allocate and signal that combined
label? If we were to use such a label, it would have to be practical
to do so, and we would need a procedure and text for the draft.

Thanks,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 19 Nov 2009 11:45:55 +0000

> which combines the pid label + CW + hash label.
The CW is optional anyway.

We could combine the pid and the hash label if we allowed the egress PE 
to signal multiple pid-label bindings using the proposed procedures, 
though I have concerns as to how good the LB would be. Clearly the 
choice of which mapping to use would be a local matter in the ingress PE 
and the choice of how many mappings to provide would be a local matter 
for the egress PE.

- Stewart

>> If you optimize for number of labels in the stack, which is what you
>>     
> are
>   
>>>>> The question is if I have multiple LSPs from different PE(s)
>>>>>           
> through
>   
>>>>>       
>>>>>         
>>>>>           
>>>> the
>>>>     
>>>>       
>>>>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 19 Nov 2009 14:14:58 +0100

Andy,

I am happy to write a new draft, but I was suggesting to update Stewarts draft with this information. Either way is fine by me.

The way I want to signal this capability is using similar procedure as what Stewart suggested.

Cheers,
Wim

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]] 
Sent: donderdag 19 november 2009 12:27
To: HENDERICKX Wim
Cc: Luca Martini; [email-masked]; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

Wim,

Thanks,
Andy

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 19 Nov 2009 14:18:34 +0100

Stewart, I am ok with this.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: donderdag 19 november 2009 12:46
To: HENDERICKX Wim
Cc: Luca Martini; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 19 Nov 2009 13:23:42 +0000

See my earlier mail, I think that the mode of operation you wanted can 
be made to work with the existing approach.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 19 Nov 2009 13:27:14 +0000

Our emails crossed

I will add some text to make sure that this mode of operation is clear 
to everyone.

- Stewart

HENDERICKX Wim wrote:
>> Also note that The FAT PW would not be very useful with a packet PW
>>     
> that
>   
>> contains IP.
>> Let assume for a moment that 99.9% of traffic in a packet PW will be
>>     
> IP 
>   
>> I do not like the CW much , so let say that we simply encapsulate the
>>     
> IP
>   
>>> I would vote for the latter. It is not much about the label
>>>       
> uniqueness
>   
>>>>> Ok good, this is what I thought, the client LSP exist in the
>>>>>           
> "client
>   
>>>>> packet Network layer".
>>>>>
>>>>>>> Assume PE1 has a LSP to PE3 and PE2 has an LSP to PE4, how is
>>>>>>>               
> this
>   
>>>>> is being carried over the LSP. The egress PE unwraps that packet
>>>>>           
> and
>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 19 Nov 2009 14:28:12 +0100

Agreed

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: donderdag 19 november 2009 14:24
To: HENDERICKX Wim
Cc: Andrew G. Malis; [email-masked]; Luca Martini
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

- Stewart

HENDERICKX Wim wrote:
> Andy,
>
> I am happy to write a new draft, but I was suggesting to update
Stewarts draft with this information. Either way is fine by me.
that
IP
IP
uniqueness
"client
this
and

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 19 Nov 2009 12:54:51 -0800

Stewart, Wim:

Currently, there is no requirement in signaling the LB label, combining
pid-label w/ LB-label, would require the egress PE to signal many labels
per PID type which can be very large due to large number of flows. Also
combining the two labels together would decrease the entropy for LB
space (although by how much would depend on the size of PID space).
Furthermore, adding this would create another option we need to worry
about for interoperability. 

Cheers,
Ali 

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Stewart Bryant (stbryant)
> Sent: Thursday, November 19, 2009 5:27 AM
> To: HENDERICKX Wim
> Cc: [email-masked]; Luca Martini (lmartini)
> > choice of which mapping to use would be a local matter in the
ingress

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Nov 2009 09:47:52 +0000

In discussing the issues related to a mode of operation in which LDP 
issues multiple labels for the same protocol, I am told that this will 
break a number of LDP implementations (from more than one company). This 
therefore will not fly as  an approach.

This leads me back to an approach described in the draft in which the 
stack can be minimized by omitting the LB label and the CW (both of 
which are optional anyway), but with a single mapping label mapping to 
the protocol.

Not that may P routers can LB on the IP header in the payload if the CW 
is not present.

- Stewart

Stewart Bryant wrote:
> We could combine the pid and the hash label if we allowed the egress 
> PE to signal multiple pid-label bindings using the proposed 
> procedures, though I have concerns as to how good the LB would be. 
> Clearly the choice of which mapping to use would be a local matter in 
> the ingress PE and the choice of how many mappings to provide would be 
> a local matter for the egress PE.
>
> - Stewart
>
>
>
>> From: Luca Martini [mailto:[email-masked]] Sent: woensdag 18 
>> november 2009 23:18
>> To: HENDERICKX Wim
>> IP ... ( most likely it's much higher then that )
>>> From: Stewart Bryant [mailto:[email-masked]] Sent: maandag 16 
>>> november 2009 18:15
>>> To: HENDERICKX Wim
>>> If you optimize for minimum number of unique labels by separating 
>>> the functions, as per the draft, this takes 102 labels
>>>
>>>> From: Andrew G. Malis [mailto:[email-masked]] Sent: maandag 16 
>>>> november 2009 15:39
>>>> To: HENDERICKX Wim

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 23 Nov 2009 14:36:24 +0100

Stewart,

Ok understood, that multiple label per protocols breaks things. 
We can argue that the control word is valuable here if we assign the
protocol labels properly, which leads me to the next question.

Would there be value of making the protocol label static value similar
to the E-type in Ethernet and using the same codes?

Cheers,
Wim

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: maandag 23 november 2009 10:48
To: HENDERICKX Wim
Cc: [email-masked]; Luca Martini
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

- Stewart

that
IP

uniqueness
"client
this
and

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Nov 2009 15:25:39 +0000

Wim

Having a GRE style PID in the CW, or an extended version of it, was the 
approach that I first proposed, but I got pushback from two directions:

1) Using a label as a PID is more consistent with RFC3031, a subject at 
the heart of the NLTS client discussions in MPLS-TP.

2) Using a label was something that a lot of h/w is optimized for and 
hence was a better processing model. 

Certainly you can see that in a PWE3 engine (2) this might well be the 
case, because it basically keeps doing look/vector operations until it 
hits the PID and the passes the pkt to the client LSR which can probably 
be optimized to pushing a datalink header and queuing out of an 
interface. This is essentially what happens all the time in MPLS with an 
IP packet.

I eventually found these persuasive arguments.

If we use a label the values have to be dynamic (they might be 
configured, but  the important point is that they are not global or 
reserved) and the rest of the design is pretty obvious.

The set of protocols defined in PPP and Ethernet are broadly the same, 
so it's not much of an issue using either. The reason that I chose the 
PPP range is because this is a pt2pt service and I wanted to emphasis 
that. Ethernet has different adjacently characteristics, and I wanted to 
make it completely clear none of that was to be used. Changing over to 
Ethertypes (as identifiers in the signaling protocol) is not a big deal, 
and I will take guidance from the WG on that.

- Stewart

>>>>> because you would have one less label (the protocol identifier),
>>>>>           
> but
>   
>>>>>> Don't you think this is a huge stack for such a function. You
>>>>>>             
> could
>   
>>>>>>               
>>>>>>             
>>>> have
>>>>      
>>>>         
>>>>>> possible here -> we could combine FAT LBL, PID LBL, CW
>>>>>>             
> potentially.
>   
>>>>>>> SB> I am not sure what you have drawn there, but it is not what
>>>>>>>               
> is
>   
>>>>>>>                         
>>>>>>>               
>>>>>> shown
>>>>>>                  
>>>>>>             
>>>>>> Think of the PW as a point to point link between a pair of PEs.
>>>>>>             
> The
>   
>>>>>>               
>>>>>>             
>>>> PE
>>>>      
>>>>         
>>>>>> chooses what traffic to sent over a given PW. The PE then pushes
>>>>>>             
> an
>   
>>>>>>               
>>>>>>             
>>>> MPLS
>>>>      
>>>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 23 Nov 2009 11:23:17 -0500

Wim,

I also initially preferred the PID embedded in the control word, but was
convinced to the current approach by implementers especially concerned with
#2 in Stewart's email. I prefer PPP PIDs rather than Ethertypes because I
need this to support the same set of protocols that you would find carried
over a PoS link, no more or less.

Cheers,
Andy

On Mon, Nov 23, 2009 at 10:25 AM, Stewart Bryant <[email-masked]> wrote:

> HENDERICKX Wim wrote:
>
>> Stewart,
>>
>> Ok understood, that multiple label per protocols breaks things. We can
>> argue that the control word is valuable here if we assign the
> 1) Using a label as a PID is more consistent with RFC3031, a subject at the
> heart of the NLTS client discussions in MPLS-TP.
>
> 2) Using a label was something that a lot of h/w is optimized for and hence
> was a better processing model.
> case, because it basically keeps doing look/vector operations until it hits
> the PID and the passes the pkt to the client LSR which can probably be
> optimized to pushing a datalink header and queuing out of an interface. This
> is essentially what happens all the time in MPLS with an IP packet.
>
> If we use a label the values have to be dynamic (they might be configured,
> but  the important point is that they are not global or reserved) and the
> rest of the design is pretty obvious.
>
> The set of protocols defined in PPP and Ethernet are broadly the same, so
> it's not much of an issue using either. The reason that I chose the PPP
> range is because this is a pt2pt service and I wanted to emphasis that.
> Ethernet has different adjacently characteristics, and I wanted to make it
> completely clear none of that was to be used. Changing over to Ethertypes
> (as identifiers in the signaling protocol) is not a big deal, and I will
> take guidance from the WG on that.
>
> - Stewart
>
>
>  Cheers,
>> Wim
>>
>> From: Stewart Bryant [mailto:[email-masked]] Sent: maandag 23
>> november 2009 10:48
>> To: HENDERICKX Wim
>> issues multiple labels for the same protocol, I am told that this will break
>> a number of LDP implementations (from more than one company). This
>>
>> stack can be minimized by omitting the LB label and the CW (both of which
>> are optional anyway), but with a single mapping label mapping to the
>> protocol.
>>
>> Not that may P routers can LB on the IP header in the payload if the CW is
>> not present.
>>
>> - Stewart
>>
>>
>>
>> Stewart Bryant wrote:
>>
>>
>>> HENDERICKX Wim wrote:
>>>
>>>
>>> to signal multiple pid-label bindings using the proposed procedures, though
>>> I have concerns as to how good the LB would be. Clearly the choice of which
>>> mapping to use would be a local matter in the ingress PE and the choice of
>>> how many mappings to provide would be
>>>
>>>
>>
>>
>>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 23 Nov 2009 20:22:04 +0100

Andy,

I am fine either way. I seem to go through the same reasoning as you did
before. Thanks for clarifying.

Cheers,

Wim

From: Andrew G. Malis [mailto:[email-masked]] 
Sent: maandag 23 november 2009 17:23
To: HENDERICKX Wim; [email-masked]
Cc: Luca Martini; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

Wim,

I also initially preferred the PID embedded in the control word, but was
convinced to the current approach by implementers especially concerned
with #2 in Stewart's email. I prefer PPP PIDs rather than Ethertypes
because I need this to support the same set of protocols that you would
find carried over a PoS link, no more or less.

Cheers,
Andy

On Mon, Nov 23, 2009 at 10:25 AM, Stewart Bryant <[email-masked]>
wrote:

HENDERICKX Wim wrote:

Stewart,

Wim

- Stewart

	Cheers,
	Wim
	
	-----Original Message-----
	From: Stewart Bryant [mailto:[email-masked]] Sent: maandag
23 november 2009 10:48
	To: HENDERICKX Wim
	Cc: [email-masked]; Luca Martini
	Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
	
	In discussing the issues related to a mode of operation in which
LDP issues multiple labels for the same protocol, I am told that this
will break a number of LDP implementations (from more than one company).
This

	This leads me back to an approach described in the draft in
which the stack can be minimized by omitting the LB label and the CW
(both of which are optional anyway), but with a single mapping label
mapping to the protocol.
	
	Not that may P routers can LB on the IP header in the payload if
the CW is not present.
	
	- Stewart

	Stewart Bryant wrote:

	HENDERICKX Wim wrote:

	Luca, for IP you are right in terms of protocol stack but I have
the
	impression that the packet-PW draft is more generic and we
should be
	open minded to other applications apart from IP.
	
	What I propose is to have 1. tunnel label - 2. pw label - 3. a
label
	which combines the pid label + CW + hash label.

	We could combine the pid and the hash label if we allowed the
egress PE to signal multiple pid-label bindings using the proposed
procedures, though I have concerns as to how good the LB would be.
Clearly the choice of which mapping to use would be a local matter in
the ingress PE and the choice of how many mappings to provide would be

	
	- Stewart

	-----Original Message-----
	
	Wim,
	
	We can , of course , always reduce the label stack depth by
merging labels, but that is usually not a good idea , as it will
increase the

		number of labels, that that is the most expensive part
of MPLS.
		Also note that The FAT PW would not be very useful with
a packet PW

	that

		contains IP.
		Let assume for a moment that 99.9% of traffic in a
packet PW will be IP ... ( most likely it's much higher then that )
		I do not like the CW much , so let say that we simply
encapsulate the

	IP

		packet into a protocol label, a PW label, and a tunnel
label.
		That's a 3 label stack , with excellent load sharing
capabilities. If

		you pull the PID out into a CW , for example , you will
have to add another label , and also make the encapsulation process much
more complicated at the PE.
		So , for this application it's better to just have 3
labels.
		
		Luca

		
		HENDERICKX Wim wrote:

		I would vote for the latter. It is not much about the
label

	uniqueness

			If we embed the e-type in the label it becomes
more easy as well.
			
			-----Original Message-----
			From: Stewart Bryant [mailto:[email-masked]]
Sent: maandag 16 november 2009 18:15
			To: HENDERICKX Wim
			Cc: Andrew G. Malis; [email-masked]
			Subject: Re: [PWE3]

			
			If you optimize for minimum number of unique
labels by separating the functions, as per the draft, this takes 102
labels
			
			If you optimize for number of labels in the
stack, which is what you

		are

		- Stewart

		
		HENDERICKX Wim wrote:

		This is correct but could we not optimize this special
mapping ?
		
		-----Original Message-----
		From: Andrew G. Malis [mailto:[email-masked]] Sent:
maandag 16 november 2009 15:39
		To: HENDERICKX Wim
		Cc: [email-masked]; [email-masked]
		Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
		
		Wim,
		
		It's still more efficient on the wire than a simulated
Ethernet PW,
		because you would have one less label (the protocol
identifier),

	but

				would add the Ethernet MAC header
instead.
				
				Cheers,
				Andy
				
				On Mon, Nov 16, 2009 at 9:03 AM,
HENDERICKX Wim
				<[email-masked]>
wrote:

				Ok good, this is what I thought, the
client LSP exist in the

	"client

				packet Network layer".
				
				Don't you think this is a huge stack for
such a function. You

	could

			have

				4-6 LBL(s) + CW (optionally). I
understand this proposal re-uses
				existing functions defined in MPLS, but
there are lot's of

			optimizations

				possible here -> we could combine FAT
LBL, PID LBL, CW

	potentially.

				-----Original Message-----
				From: Stewart Bryant
[mailto:[email-masked]]
				Sent: maandag 16 november 2009 14:49
				To: HENDERICKX Wim
				Cc: [email-masked]
				Subject: Re: [PWE3]
draft-bryant-pwe3-packet-pw-02.txt

				           --------
--------
				  PE1-----|        |
|        | --- PE3
				          |  LSR   |------- PKT PW
------|  LSR   |
				          |        |
|        |
				  PE2-----|        |
|        |---- PE4
				           --------
--------
				
				Assume PE1 has a LSP to PE3 and PE2 has
an LSP to PE4, how is

	this

	

				SB> I am not sure what you have drawn
there, but it is not what

	is

				shown

				in  the draft. The pkt pw run between
the PEs and is carried over

			the

				LSPs. PWs are distinguished from each
other at the PE via the PW

				label.

				WH> What I tried to draw is PE(s)
attached to the device (drawn

		with

				the

				box) which is performing the LSR
function on a PKT PW to another

				device

				(drawn with the box) which attaching
PE(s).
				
				The question is if I have multiple LSPs
from different PE(s)

		through

				the

				PKT PW how are the distinguished. Do I
need a separate PID LBL, a
				separate PW, etc such that the LSR can
make the correct LBL

		mappings.

			Wim
			
			Think of the PW as a point to point link between
a pair of PEs.

	The

			PE

				chooses what traffic to sent over a
given PW. The PE then pushes

	an

			MPLS

				label to identify the destination. The
mid-point LSRs have no clue

			what

				is being carried over the LSP. The
egress PE unwraps that packet

	and

				RFC3985 applies to pkt pw as it does to
any other PW.
				
				- Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 23 Nov 2009 14:12:33 -0800

Hi Stewart,

Isn't it simpler to use a PW for MPLS/MPLS-TP payload and then use GACH for the other types of traffic carried inside that PW?

Thanks,
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, November 23, 2009 1:48 AM
To: HENDERICKX Wim
Cc: Luca Martini; [email-masked]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt

- Stewart