[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: John E Drake
Date: Mon, 29 Mar 2010 12:45:44 -0700

The e-mail to which I was replying stated that there might be packet  
re-ordering, and I was just pointing out that a reasonable  
implementation can avoid either packet re-ordering or loss.

I seriously doubt that per flow shaping is done on links between core  



Sent from my iPhone

On Mar 29, 2010, at 12:28 PM, "Mcdysan, David E" <[email protected] 
 > wrote:

> Hi John,
> The scenario I had in mind was as follows:
> 1. An LSP is currently placed on Component Link 1 (CL.1)
> 2. A request is made to move this LSP to Component Link 2 (CL.2)
> 3. An LSP (segment) is Made on CL.2 Before Breaking the LSP  
> (segment) on
> CL.1
> 4. At some point in time (t1) the router stops sending packets from  
> the
> flow from the LSP (segment) on CL.1 and begins sending these packets  
> on
> the LSP on CL.2
> Define the difference between the latency of CL.2 and latency of CL. 
> 1 as
> Delta.
> Define amount of time that the last packet of the flow is sent on CL.1
> as t0 and the time that the first packet is sent on CL.2 as t2.
> By construction t0 <= t1 <=t2.
> If Delta>0 and Delta>(t2-t0) then at least one packet on CL.1 will
> arrive before the first packet arrives from CL.2, and at least these  
> two
> packets will be out of order.
> If Delta=0 then there is no problem and there truly is no disruption.
> If Delta< 0 then two packets that were shaped so as to be spaced out  
> in
> a regular way will become clumped together, increasing short-term  
> delay
> variation as perceived by the receiver.
> Only when Delta=0 is this truly "non-disruptive," but I would consider
> the above scenario "minimally disruptive" in the sense that there is  
> no
> loss. However, as was commented by several people controlling the
> frequency of such MBB LSP "movements" is an operational requirement.
> Thanks,
> Dave
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> On Behalf Of John E Drake
>> Sent: Monday, March 29, 2010 2:55 PM
>> To: Mcdysan, David E
>> Cc: [email protected]
>> Subject: Re: composite link - candidate for respin, maybe
>> Dave,
>> If, when an LSP is being moved from one component link to
>> another with MBB, packets of given flow are all placed on the
>> same component link, there shouldn't be an issue with packet
>> re-ordering even if the two links have different delays.
>> Thanks,
>> John
>> Sent from my iPhone
>> On Mar 29, 2010, at 11:23 AM, "Mcdysan, David E"
>> <[email protected]  > wrote:
>>> Hi John,
>>> Comments in line.
>>> Thanks,
>>> Dave
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:[email protected]] On
>>>> Behalf Of John E Drake
>>>> Sent: Monday, March 29, 2010 11:57 AM
>>>> To: Tony Li; [email protected]
>>>> Cc: [email protected]
>>>> Subject: RE: composite link - candidate for respin, maybe
>>>> Comments inline
>>>>> -----Original Message-----
>>>>> From: [email protected]
>>>> [mailto:[email protected]] On Behalf
>>>>> Of Tony Li
>>>>> Sent: Sunday, March 28, 2010 10:38 PM
>>>>> To: [email protected]
>>>>> Cc: [email protected]
>>>>> Subject: Re: composite link - candidate for respin, maybe
>>>>> Hi Curtis,
>>>>>> What we don't want to do (IMHO) is completely remove
>>>> aggregation of
>>>>>> the bundle (aka CL) advertisement.  If there are a dozen
>>>> identical
>>>>>> links and four that are differnt there is no need to
>> pick exactly
>>>>>> one, just one from either set, or don't care.
>>>>> My concern is that down the road, as resources get used,
>>>> the links will no
>>>>> longer be identical.   Each will have its own unique usage
>>>> levels.  Global
>>>>> planning and optimization can use this information to determine
>>>>> exactly how many LSPs and at what sizes can fit down the link.
>>>> [JD]
>>>> Then why bother with link bundling? This level of control has been
>>>> part of TE since the beginning.  Link bundling was introduced to
>>>> trade information hiding for scalability.
>>> This is a key point.
>>> As mentioned in the current draft and as one of the first operator
>>> stories that I told in the meeting is the current practice
>> is to keep
>>> the links separate since link bundling aggregation loses too much
>>> information. If latency is important, then setting the TE-metric
>>> proportional to the latency meets some of the requirements.
>> However,
>>> if one wants to set the TE-metric as a funciton of something other
>>> than latency, then the status quo does not allow some customer or
>>> internal use requirements in terms of latency to be supported.
>>> Some form of composition (or bundling) in routing must give some
>>> benefit in terms of scalability/ stability as compared with
>> separate
>>> links.
>>>>>> If we don't put a bound on the number of sets, in the limit each
>>>>>> component could be advertised with the added semantic
>>>> that there is a
>>>>>> sharing option.  In that case the LSP may need to specify
>>>> the set of
>>>>>> "groups" (as I have it above in the absense of a term) that are
>>>>>> acceptable.  This could make for a very big ERO.  It should be
>>>>>> adequate to indicate in the RRO that the bundle is being
>>>> used with a
>>>>>> field indicating which member was currently in use (if nailed in
>>>>>> place).  This is beyond requirements, so if we are OK
>>>> with the stated
>>>>>> requirement, let defer the details to later.
>>>>> I'm fine with that, but we may also want to specify the
>>>> component in the
>>>>> ERO.
>>>> [JD]
>>>> See
>> http://datatracker.ietf.org/doc/draft-ietf-mpls-explicit-resource- 
>> cont
>>> ro
>>> l-bundle/
>>> Being able to identify the component link on which an LSP is placed
>>> (or spread across) is I believe a requirement which we need to
>>> capture, which it appears this draft is proposing a
>> specific solution.
>>>>>> OK.  So what is your objection?  Are you suggesting that
>>>> we need to
>>>>>> restrict the load balance to look down N labels from the
>>>> top and no
>>>>>> further?
>>>>> No, I'm suggesting that we need a bit in the RESV to say
>>>> that this LSP
>>>>> should be demuxed by inner labels or kept atomic.
>>>> [JD]
>>>> In current link bundling an LSP is either assigned to a specific
>>>> component link or split across all of the component links.  In the
>>>> latter case this effectively means all or a subset of the
>> component
>>>> links.
>>>> If an LSP is assigned to a specific component link, RFC 5150
>>>> (http://datatracker.ietf.org/doc/rfc5150/) (a one hop LSP on the
>>>> assigned component link) and MBB can be used to move the LSP
>>>> non-disruptively to another component link
>>> minimal disruption. Some disruption (e.g., packet reordering) could
>>> occur if the links have different latencies.
>> _______________________________________________
>> rtgwg mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/rtgwg
rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>