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

["Stefano Previdi (sprevidi)" <[e-mail]>]

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.
>