Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

["Les Ginsberg (ginsberg)" <[e-mail]>]

Chris -

I understood what you intended from your original post. The extension you are suggesting makes it "more convenient" to configure SIDs for multiple topologies since you can use the same index in multiple SRGBs. But it is possible to support your use case w a single SRGB.

Now, could you please acknowledge the points I made?

1)You are fundamentally changing the context associated w an SRGB

2)You are now REQUIRING the use of multiple SRGBs to support the full set of SR use cases (currently one SRGB is sufficient)

3)You are introducing new requirements on how a given router allocates local labels

4)The backwards compatibility issues w existing deployments are much greater w your proposal 

Given the concern about existing deployments #4 alone seems sufficient to not go in the direction you suggest. But the other three points add considerable additional weight to the argument against your proposal.

   Les


> -----Original Message-----
> From: Chris Bowers [mailto:[e-mail]]
> Sent: Tuesday, March 31, 2015 12:07 PM
> To: Les Ginsberg (ginsberg); Hannes Gredler; Stefano Previdi (sprevidi)
> Cc: [e-mail] list; draft-ietf-isis-segment-routing-
> [e-mail]
> Subject: RE: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-
> extensions
> 
> Les,
> 
> Here is a practical example of the issue with using per-algorithm node-SIDs.
> Suppose an operator has a network with 100 nodes (R0 -R99).  They assign
> unique Node-SIDs 0-99 to those nodes for algorithm=0, in order to
> accomplish shortest path routing based on IGP metric with SR labels.  Each
> node will need to advertise a label block of size=100.
> 
> Assume that at some future point in time, the IETF defines algorithm=1 to
> mean shortest path routing based on latency, and vendors implement this.
> Suppose that the operator wants to use latency-based SPF routes for some
> traffic and metric-based SPF routes for other traffic.   The operator will need
> to define a new set of unique Node-SIDs for algorithm=1.  A reasonable
> choice would be to assign Node-SID values of 100-199 to R0-R99 for
> algorithm=1.  Each node will now need to advertise a label block of size=200.
> So far the need for per-algorithm node-SIDs is an annoyance, but not too
> difficult to deal with.
> 
> Now assume that the operator needs to add 10 new nodes to the SR domain,
> specifically nodes R100-R109.  Each node needs to advertise a label block of
> size=220.   The main issue is deciding how to assign per-algorithm node-SIDs
> for the 10 new nodes?  One option is to redo the node-SID numbering
> scheme so that R0-R109 have node-SIDs 0-109 for algorithm=0 and node-SIDs
> 110-229 for algorithm=1.  However, this require renumbering existing nodes.
> The other option is to avoid renumbering of nodes by assigning nodes R100-
> R109 node-SIDs 200-209 for algorithm=0 and node-SIDs 210-219 for
> algorithm=1. Each of these options has drawbacks.  The first requires
> renumbering existing nodes, while the second is difficult to maintain since
> there is no obvious relationship between the node-SIDs for different
> algorithms.
> 
> Instead, the use of per-algorithm label-blocks avoids this problem
> completely.  When the SR domain is initially deployed, R0-R99 can be
> assigned node-SIDs 0-99 as one would expect.  When support for
> algorithm=1 gets added,  the operator does not need to assign and configure
> any new node-SIDs.  Instead, the routers automate the process by
> advertising different label blocks for each algorithm.  When another 10 nodes
> get added to the SR domain, R100-R109 get assigned node-SIDs 100-109 as
> one would expect.  And the router advertises a label block of size=110 for
> each algorithm, as one would expect.  Adding new nodes in the presence of
> multiple algorithms is simplified significantly with the use of per-algorithm
> label blocks.
> 
> As you point out, the same logic applies to multiple topologies, so it would
> make sense to advertise per-topology label blocks.
> 
> There are other numbering schemes for per-algorithm node-SIDs that one
> can consider, but as far as I can tell, they run into problems when trying to
> add more nodes or more algorithms.  One could also lessen the impact of this
> somewhat by anticipating growth in each of the dimensions (number of
> nodes, number of algorithms, and number of topologies) and pre-assigning
> node-SIDs based on anticipated maximum values in each dimension, but this
> can result in advertising label blocks that are potentially much larger than
> actually needed.
> 
> Chris
> 
> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Monday, March 30, 2015 2:58 PM
> To: Hannes Gredler; Stefano Previdi (sprevidi)
> Cc: [e-mail] list; draft-ietf-isis-segment-routing-
> [e-mail]
> Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-
> extensions
> 
> Hannes/Chris -
> 
> There is a rather large conceptual change being proposed here.
> 
> At present, the SRGB advertisements specify the label range(s) which a given
> node has reserved for use by SR - no further restrictions are defined. In most
> cases multiple vendors have indicated that a single SRGB range is sufficient -
> but the specification allows for advertisement of multiple ranges in case the
> label space on a given node is fragmented such that multiple ranges might be
> required. The suggested change Stefano has posted makes no change to this
> other than a very minor format change that restricts the advertisement to a
> single TLV for ease of use.
> 
> What the two of you are proposing is that we fundamentally change SRGB
> advertisements so that each range is tied to a specific SR use case. At present
> you are only proposing "algorithm" - but it would be just as logical to propose
> other contexts (for example "per topology" ranges) as well. This makes a
> very fundamental change in the functionality associated w an SRGB. It is no
> longer simply a range reserved for use by SR - it becomes a range reserved
> for a particular SR use case - which means multiple SRGBs would no longer be
> an option to address a local label allocation issue, but required to support all
> SR use cases. The backwards compatibility issues are MUCH LARGER and
> introduce a fundamental change in the attributes of an SRGB range. It will
> also have implications on how nodes support local label allocation.
> 
> I don't think this is necessary nor is it desirable.
> 
>    Les
> 
> 
> > -----Original Message-----
> > From: Isis-wg [mailto:[e-mail]] On Behalf Of Hannes
> > Gredler
> > Sent: Monday, March 30, 2015 6:27 AM
> > To: Stefano Previdi (sprevidi)
> > Cc: [e-mail]; isis-
> > [e-mail] list
> > Subject: Re: [Isis-wg] Proposed Changes in
> > draft-ietf-isis-segment-routing- extensions
> >
> > hi stefano,
> >
> > On Sun, Mar 29, 2015 at 10:06:08PM +0000, Stefano Previdi (sprevidi)
> wrote:
> > | Hi Chris, Pushpasis,
> > |
> > | sorry but I disagree.
> > |
> > | The current proposal is a minor change that, will not incur ANY
> > | backward
> > compatibility change (since nobody advertises multiple srgb's at this
> > stage) while your proposal makes a radical change in the format of the
> > sr-cap subtlv that would impact current deployments.
> > |
> >
> > have spoken to chris offline - what he wants to do is add the algo-ID
> > to the SRGB.
> >
> >   my understanding is that this is required for resilient packet-rings
> > in the access
> >   which have very constrained MPLS stacking capabilities (and R-LFA
> > with its two labels
> >   blows the stacking budget and MRT single label does not) ...
> >
> > The change is not as radical as it sounds - "if an implementation does
> > not support a non-zero algo-ID then it MUST ignore the SRGB"
> >
> > and
> >
> > "Every implementation MUST support the SRGBs with algo-id of zero"
> >
> > /hannes
> >
> > | On Mar 27, 2015, at 2:33 PM, Pushpasis Sarkar <[e-mail]>
> > wrote:
> > |
> > | > Hi Chris,
> > | >
> > | > I fully agree to your proposal of a separate SRGB per algorithm
> > | > (e.g. SPF, MRT-Blue, MRT-Red).
> > | >
> > | > Regarding your comment on Multi-topology.. Today, MT in ISIS is
> > | > different than MT in OSPF. I think OSPF already has MT built-in
> > | > the OSPF protocol extension. However there is no such need to
> > | > extend that for ISIS, unless we intend to do OSPF-like MTR.
> > | >
> > | > Thanks,
> > | > -Pushpasis
> > | >
> > | > On 3/27/15, 8:22 AM, "Chris Bowers" <[e-mail]> wrote:
> > | >
> > | >> All,
> > | >>
> > | >> Since the changes being proposed to the ISIS SR extensions will
> > | >> break backwards compatibility, I would like to suggest that that
> > | >> working group consider taking advantage of this opportunity to
> > | >> improve the way that SR extensions support forwarding based on
> > algorithms other than SPF.
> > | >>
> > | >> Currently, in order to establish forwarding next-hops based on
> > | >> another algorithm, each node must be configured with an
> > | >> additional
> > node-SID, each
> > | >> unique in the IGP domain.    The configuration and management of
> > unique
> > | >> node-SIDs on a per-algorithm basis can be avoided by having each
> > | >> node assign a label block for each algorithm and advertise label
> > | >> blocks on a per-algorithm basis.  In this way, a given node only
> > | >> needs to have a single unique node-SID configured, while still
> > | >> supporting forwarding next-hops computed by different algorithms.
> > | >>
> > | >> As far as I can tell, the main drawback of this approach is that
> > | >> it would break backwards compatibility with existing
> > | >> implementations since the current extensions do not support the
> > | >> association of an algorithm with a label block.  However, if we
> > | >> group this change together with other non-backwards compatible
> > | >> changes, that drawback is minimized or eliminated.
> > | >>
> > | >> It may also make sense to take this opportunity to improve
> > | >> support for multi-topology routing in SR by introducing a
> > | >> mechanism to allow the SR-related sub-TLVs carried in the Router
> > | >> Capability TLV to be associated with a given MT-ID.
> > | >>
> > | >> Chris
> > | >>
> > | >> -----Original Message-----
> > | >> From: Isis-wg [mailto:[e-mail]] On Behalf Of
> > | >> Stefano Previdi (sprevidi)
> > | >> Sent: Wednesday, March 25, 2015 6:42 AM
> > | >> To: [e-mail] list
> > | >> Cc: [e-mail]
> > | >> Subject: [Isis-wg] Proposed Changes in
> > | >> draft-ietf-isis-segment-routing-extensions
> > | >>
> > | >> All,
> > | >>
> > | >> The authors of draft-ietf-isis-segment-routing-extensions would
> > | >> like to expose the following proposed changes to SRGB
> > | >> advertisement which are being considered.
> > | >>
> > | >> 1. Single Vs. Multiple SRGB ranges Currently, section 3.1.
> > | >> SR-Capabilities Sub-TLV defines that:
> > | >>
> > | >> "A router not supporting multiple occurrences of the
> > | >> SR-Capability sub-TLV MUST take into consideration the first
> > | >> occurrence in the received set."
> > | >>
> > | >> The authors would like to remove above text so that a compliant
> > | >> implementation MUST support the receiving of multiple ranges.
> > | >>
> > | >> 2. Encoding the SR-Cap in a single LSP Fragment Vs. Single TLV
> > | >> Currently, section 3.1.  SR-Capabilities Sub-TLV defines that:
> > | >>
> > | >> "The SR Capabilities sub-TLV (Type: TBD, suggested value 2) MAY
> > | >> appear multiple times inside the Router Capability TLV and has
> > | >> following format [...]"
> > | >>
> > | >> and
> > | >>
> > | >> "Only the Flags in the first occurrence of the sub-TLV are to be
> > | >> taken into account"
> > | >>
> > | >> and
> > | >>
> > | >> "The originating router MUST encode ranges each into a different
> > | >> SR-Capability sub-TLV and all SR-Capability TLVs MUST be encoded
> > | >> within the same LSP fragment."
> > | >>
> > | >> and
> > | >>
> > | >> "The order of the ranges (i.e.: SR-Capability sub-TLVs) in the
> > | >> LSP fragment is decided by the originating router and hence the
> > | >> receiving routers MUST NOT re-order the received ranges. This  is
> > | >> required for avoiding label churn when for example a  numerical
> > | >> lower Segment/Label Block gets added to an already  advertised
> > | >> Segment/Label Block."
> > | >>
> > | >> Authors agreed that:
> > | >> . the encoding scheme is suboptimal and doesn't make best use of
> > | >>   the TLV/LSP space (e.g.: flags field is replicated and unused).
> > | >> . we want to preserve the requirement of NOT sorting the received
> > | >>   srgb ranges in order to avoid churns and downtime when a change
> > | >>   is advertised (typically when the srgb is extended).
> > | >>
> > | >> Therefore a possible option is to restrict the advertisement of
> > | >> multiple srgb's into the SAME SR-Cap SubTLV where flags get
> > | >> defined once and srgb ranges encoded within the same (unique)
> > | >> SR-Cap SubTLV (btw, we still have room for up to 27 srgb ranges).
> > | >>
> > | >> Now, doing this will improve the encoding and clarity of the spec
> > | >> but introduces a backward compatibility issue with current
> > | >> version of the draft. Therefore it is important that all
> > | >> implementors make themselves known and tell the authors how
> > | >> difficult this change is from an implementation perspective.
> > | >>
> > | >> Among the authors we have 4 implementors for which the change
> > seems
> > | >> not to be a problem but other implementations of ISIS, Segment
> > | >> Routing extension may exists and so it is necessary to check
> > | >> whether anyone has a problem with the proposed change.
> > | >>
> > | >> Thanks.
> > | >> s.
> > | >>
> > | >> _______________________________________________
> > | >> Isis-wg mailing list
> > | >> [e-mail]
> > | >> https://www.ietf.org/mailman/listinfo/isis-wg
> > | >>
> > | >> _______________________________________________
> > | >> Isis-wg mailing list
> > | >> [e-mail]
> > | >> https://www.ietf.org/mailman/listinfo/isis-wg
> > | >
> > |
> > | _______________________________________________
> > | Isis-wg mailing list
> > | [e-mail]
> > | https://www.ietf.org/mailman/listinfo/isis-wg
> >
> > _______________________________________________
> > Isis-wg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/isis-wg
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg