[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] draft-bryant-pwe3-packet-pw-02.txt
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
On Thu, Nov 19, 2009 at 3:22 AM, HENDERICKX Wim
<wim.henderickx at alcatel-lucent.be> 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.
>
> -----Original Message-----
> From: Luca Martini [mailto:lmartini at cisco.com]
> Sent: woensdag 18 november 2009 23:18
> To: HENDERICKX Wim
> Cc: stbryant at cisco.com; pwe3 at ietf.org
> 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:stbryant at cisco.com]
>> Sent: maandag 16 november 2009 18:15
>> To: HENDERICKX Wim
>> Cc: Andrew G. Malis; pwe3 at ietf.org
>> 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:amalis at gmail.com]
>>> Sent: maandag 16 november 2009 15:39
>>> To: HENDERICKX Wim
>>> Cc: stbryant at cisco.com; pwe3 at ietf.org
>>> 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
>>> <wim.henderickx at alcatel-lucent.be> 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:stbryant at cisco.com]
>>>> Sent: maandag 16 november 2009 14:49
>>>> To: HENDERICKX Wim
>>>> Cc: pwe3 at ietf.org
>>>> 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
>>>> pwe3 at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> pwe3 at ietf.org
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
>
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>