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
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
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.
> -----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
> 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.
> 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.
> > 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
> > 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
> > 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
> >> 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]
rtgwg mailing list