Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP => ~ETH aggregation?

[Stewart Bryant <[e-mail]>]

Curtis

Whilst operation over link bundles is an important issue, it will take 
some time to fully understand the implications and design a solution.

In the interests of completing our committed deliverables to the ITU-T 
in a timely manner, can I propose that we continue to exclude them from 
the current MPLS-TP drafts.  Can I also propose that in the meanwhile, 
you or others that wish to pursue technology to support link bundles, 
publish drafts which update the MPLS-TP specifications and describe the 
necessary requirements and technical solutions to address this problem.

- Stewart


Curtis Villamizar wrote:
> In message <[e-mail]>
> Stewart Bryant writes:
>   
>>  
>> Curtis Villamizar wrote:
>>     
>>> In message <[e-mail]>
>>> Stewart Bryant writes:
>>>   
>>>       
>>>>  
>>>> I would think that if the operator wanted the bandwidth more than they 
>>>> wanted the fate sharing, they will deploy the technology.
>>>>  
>>>> - Stewart
>>>>     
>>>>         
>>> There is no reason not to put some entropy in the extension to MPLS
>>> Ping so that there was fate sharing over LAG.
>>>
>>> Curtis
>>>  
>>>
>>>   
>>>       
>> Curtis
>>  
>> Do you have some text in mind?
>>  
>> - Stewart
>>     
>
>
> Remove from section 3.1.1:
>
>    Per-packet Equal-Cost Multi-Path (ECMP) load-balancing is outside the
>    scope of the MPLS-TP.
>
> BTW- per packet load balance was the name given to the technique in
> the 1990s of just round robin distribution across ECMP paths that
> resulted in horrible performace problems if applied to WAN.  The IP
> src/dst hash techniques were the "other technique".
>
> Add a subsection (somewhere, your choice):
>
>   3.x.x
>
>    While Equal-Cost Multi-Path (ECMP) load-balancing is outside the
>    scope of the MPLS-TP, its use is common particularly in link
>    aggregation applications and may continue to be common.
>
>    MPLS-TP implementations MAY support optional mechanisms to add
>    entropy to the MPLS label stack when sending OAM traffic as defined
>    for PW [draft-ietf-pwe3-fat-pw].  Inserting an additional entropy
>    label under the GAL label would serve a similar purpose as the use
>    as provided by the 127.x sender address space in MPLS Ping.
>
>    If future MPLS implementations ignore the GAL label in EMCP
>    hashing, but compute a hash based labels before and after this
>    label, as if the GAL label was not present, then MPLS Ping can be
>    used to disagnose the exact path, including the exact link
>    aggregation members taken for a given client label stack.
>
> Note that this would be better if we also had a draft that specified
> using labels under GAL only for entropy.  The intermediate nodes that
> see a lable above the GAL label (above being further from the BOS)
> SHOULD ignore the GAL label in hashing.  When the GAL label is
> encountered, all labels below the GAL label would be disposed of or
> optionally delivered to the application.  I'm a little short on spare
> time but maybe someone else might try.
>
> In both PW there is never MPLS labels below the PW label except the
> flow label used in flow label defined in draft-ietf-pwe3-fat-pw-03.
> In GAL there is currently nothing below the GAL label but adding an
> entropy label for OAM purposes just in case there is a LAG in the
> middle would be useful, and at this stage not harmful since
> implementations of GAL mostly just kick GAL along with everything else
> in the reserved range up to the processor and no GAL specific
> processing is yet cast in silicon.
>
> Curtis
>
> btw- you could probably word this better.
>
>   


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html