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

["Henderickx, Wim (Wim)" <[e-mail]>]

I agree and I would like to keep the changes to a minimum to ensure we provide backward compatibility with shipping code.




On 30/03/15 21:57, "Les Ginsberg (ginsberg)" <[e-mail]> wrote:

>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