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

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

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