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

[<[e-mail]>]

Chris,

I understand why you picked this thread to introduce your proposal. However,
- Stefano's email was clear and focused on resolving a specific point. (and thanks Stefano for your email on the list). I think that's really best to keep the thread focused in order to resolve/close this point (ASAP).
- Your point is much broader. Broader than this thread and broader than this IS-IS draft. I think it would be more related to the SPRING WG.

If you want to have this point discussed, I would encourage you to bring this to the SPRING WG in an appropriate thread. e.g. related to the architecture document, or a new document that you would post.
It would be good to consider the whole picture, and in particular the impact on the spring architecture, on both IGP (IS-IS, OSPFv2, OSPFv3 protocol extensions) and on both SPRING data planes (MPLS, IPv6).

Then if SPRING adopt this proposal, I'm confident that the IS-IS WG will be able to propose an encoding, hopefully in a backward compatible way. (e.g. through a new sub-TLV or by modifying the SR-Algorithm Sub-TLV which is probably not (fully) implemented (e.g. by adding a SRGB offset for Algorithms in order to define SRGB sub-range, while keeping a single global SRGB))

Thanks,
Bruno
> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Chris Bowers
> Sent: Tuesday, March 31, 2015 9: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
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.