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

From: [email-masked]
Date: Mon, 7 Dec 2009 15:15:42 +0800

Hi,everyone
maybe I not see what you said very clearly. here I ask the author of this 
draft about the following question:
  1 whether PID label will only be used for MPLS/MPLS-TP client service? 
when the client service is L1 or L2 service ,eg. ATM, SDH,ETH.  don't we 
need  PID label to identify the type of client service?
   if the answer is yes, why do we use different way for different client 
services? why not to use the same way for all client services inlcude 
ATM,SDH,ETH ,MPLS/MPLS-TP ?
  2 this draft describles the benefits of using PID label is to multiplex 
various data-link types into a pseudowire. but in reality, is it necessary 
to carry more one types client services in the same pseudowire? I don't 
see this applyment in real network till now .

  3 when there is  PID Label between pw label and CW field for 
MPLS/MPLS-TP client service. how to set S field value for PW label and PID 
label?
    whether we set S=O in the PW label and set S=1 in the PID Label? if 
so. is it possible to regard PID label as PW label wrongly in the egress 
node?

 maybe my understanding for this draft be false or not completely true? 

best regards
liu

"Shahram Davari" <[email-masked]> 
发件人:  [email-masked]
2009-11-24 06:12

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

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

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:
> 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.
>> 
> 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
>
>
>
>> -----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,
>>
>> 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
>>> 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
>>>
>>> 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:
>>> 
>>>> 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
>>>>>
>>>>> 
>>>>>>> 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 ?
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>> 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
>>>>> figures out what the payload is.
>>>>>
>>>>> RFC3985 applies to pkt pw as it does to any other PW.
>>>>>
>>>>> - Stewart
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> pwe3 mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>>
>>>>> 
>>>> 
>>> _______________________________________________
>>> pwe3 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pwe3
>>> 
>>
>>
>>
>> 
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

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

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

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