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

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

+1

   Les

> -----Original Message-----
> From: Stefano Previdi (sprevidi)
> Sent: Wednesday, April 01, 2015 3:12 AM
> To: <[e-mail]>
> Cc: Chris Bowers; [e-mail] list; draft-ietf-isis-segment-routing-
> [e-mail]; Les Ginsberg (ginsberg); Hannes Gredler; John
> Scudder
> Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-
> extensions
> 
> Bruno,
> 
> I fully support your proposal.
> 
> s.
> 
> 
> On Apr 1, 2015, at 12:03 PM, <[e-mail]> wrote:
> 
> > 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.
> >