[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 01:59:48 -0400
In message <[email protected]>
John E Drake writes:
>  
> > 
> > You are missing a few things.
> > 
> > One is the abilit to move LSP from one component to another.  In
> > Tony's view that would not be possible because the LSP is nailed to
> > one component, not a group with common attributes and a specification
> > of maximum dynamic.
> [JD] 
>  
> Moving a section of an LSP from one path to another does not require
> link bundling.


Yes entirely true but being able to move a pinned LSP and pin it
somewhere else is not the only requirement.



> > Another is the ability to allow an LSP to be load split across a set
> > of components.  The top LSP may (if signaling indicates this is OK) be
> > split among component links.  This is the only way to support LSP of
> > greater than 100G in the near future.
> [JD] 
>  
> The discussion was about IGP scaling.  Both examples you describe
> deal with signaling and could be decoupled from any IGP
> enhancements that are made. 


You've deleted enough context (the examples) that I'm not sure if I'm
adequately addressing your point here.

In order for an ingress to specify that some sort of load split of an
LSP cound occur it needs to know that that capability is available on
that link.  So for example, if an LSP is 180G and there are two 100G
interfaces in parallel, the ingress needs to know that this is a CL
and that it can handle this LSP.  The IGP provides that information.


> > > > > 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-
> > control-bundle/
> > 
> > 
> > The functionality I mentioned above is missing.
> [JD] 
>  
> Then you need to re-phrase your requirement (or re-read the I-D)


Again you deleted context.  By "re-phrase your requirement" I take it
that you mean just the following requirement:

  6.  A means to support non-disruptive reallocation of an existing
      LSP to another component link is needed.

There is nothing here that prohibits using stitching or any other
method.  We are not defining *how* to do anything, just what the
requirements are.

The very first paragraph reads:

  These requirements refer to link bundling solely to provide a frame
  of reference.  This requirements document does not intend to
  constrain a solution to build upon link bundling.  Meeting these
  requirements useing extensions to link bundling is not precluded, if
  doing so is determined by later IETF work to be the best solution.

What about "solely to provide a frame of reference" don't you
understand?

I don't see any point in adding that "One of these requirements might
be met by LSP stitching.  This requirements document does not intend
to constrain a solution to build upon LSP stitching.  Meeting these
requirements useing extensions to LSP stitching is not precluded, if
doing so is determined by later IETF work to be the best solution."

Do you get it now?


> > > > > 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
> > 
> > 
> > Creating every LSP by stitching one hop LSPs together is a very poor
> > solution IMO.  The requirement though do not specify a solution.
> [JD] 
>  
> It depends upon how many LSPs need this behavior.  LSP Hierarchy
> would also work.  So the requirement needs to be more precise. 


I also do not see the point of adding "One of these requirements might
be met by LSP hierarchy.  This requirements document does not intend
to constrain a solution to build upon LSP hierarchy.  Meeting these
requirements useing extensions to LSP hierarchy is not precluded, if
doing so is determined by later IETF work to be the best solution."

We are not specifying solutions at this point.  We are specifying
requirements.  Got it?

Curtis
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

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