> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, March 31, 2010 11:48 PM
> To: John E Drake
> Cc: [email protected]; Tony Li; [email protected]
> Subject: Re: composite link - candidate for respin, maybe
> 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
> > > > homogeneous bundled links versus one heterogeneous bundled link.
> > > > 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.
You are specifying a solution here. You are saying that the specific set of
component links to be used by a given LSP is identified during signaling,
rather than by data plane packet classification.
You also seem to be saying that the LSP ingress specifies the load balancing
algorithm. If so, I don't think this is a good idea.
> 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.
I don't think everyone is on the same page regarding what fields in a packet
are to be used in packet classification. Some of the text you added to the
MPLS-TP OAM framework I-D could usefully be added to the requirements I-D.
> > > > 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