[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: Thu, 1 Apr 2010 07:43:20 -0700
> -----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]
> HQ.jnpr.net>
> > > 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.
[JD] 

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.
[JD] 

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.)
> 
> OK.
> 
> > > > John
> > >
> > > Curtis
> 
> 
> Curtis
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

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