[email protected]
[Top] [All Lists]

Re: composite link - candidate for respin, maybe

Subject: Re: composite link - candidate for respin, maybe
From: Curtis Villamizar
Date: Thu, 01 Apr 2010 02:47:48 -0400
In message <[email protected]>
John E Drake writes:
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Monday, March 29, 2010 9:49 PM
> > To: John E Drake
> > Cc: Tony Li; [email protected]; [email protected]
> > Subject: Re: composite link - candidate for respin, maybe
> > 
> > 
> > In message <[email protected]>
> > John E Drake writes:
> > >
> > > Tony,
> > >
> > > Clearly there is extra overhead (roughly 2*(N - 1)* 40 bytes?) with N
> > > homogeneous bundled links versus one heterogeneous bundled link.  The
> > > concern I have is that having heterogeneous bundled links may
> > > complicate the data plane packet forwarding.
> > 
> > How the control plane information is presented does not "complicate
> > the data plane packet forwarding".
> [JD] 
> If we are placing flows on the component links of a heterogeneous link
> bundle, we may have to look at additional fields within packets and/or
> maintain additional state, relative to what is required to place flows
> on the component links of a homogeneous link bundle.  The example that
> has been given is flows that require low latency.

If the LSP requires low latency, then the LSP is signaled for low
latency.  If it asked to be pinned, all the flows in that LSP are
pinned to one component link.  That is easy, just map the label using
the ILM to one link.

If the LSP requires a particular flavor of low latency, but it doesn't
mind being load split then it is load split across only those
components that meet that latency requirement.  The top label
identifies the subset of the component links that are "fair game" and
some algorithm that the LSP has signaled it is OK to use splits the
flows among those links.

If you think about how this is implemented in routers today this is
all doable now, just not with a very good load split.  If you don't
have the slightest clue how it is done today RFC2991 and RFC2992 will
provide the slightest clue but not much more.

> The requirements document needs to be clear as to which fields in the
> packet header are to be used in packet classification.  E.g., do we
> deal strictly with the MPLS header or can the packet header also be
> used, and if so, do we have to deal with encrypted as well as
> unencrypted packets?

No it doesn't!  We are specifying requirements, not solutions.  When
we get around to specifying solutions then it does.

There is 10-15 years of history on this that says it is doable,
because it is being done so we are well beyond the point where we need
example to establish that a feasible technique exists.

> > > A clear statement as to what we are trying to accomplish wrt IGP
> > > scaling by using bundled links would be good.
> > 
> > Please indicate what in the requirements we are discussing is not
> > clear rather than a blacket statement that the goals are not clear.
> [JD] 
> I was agreeing with Tony, so please direct this question to him.
> (But, I don't see any real discussion of IGP scaling requirements.)


> > > John
> > 
> > Curtis

rtgwg mailing list
[email protected]

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