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

[Pushpasis Sarkar <[e-mail]>]

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