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

[Pushpasis Sarkar <[e-mail]>]

Hi Ahmed, Les, Stephano et al.

What we are saying that while we are making other non-backward-compatible
changes in the next version of this draft, let us consider if we can also
add some minimal more to be able address some proper kind of support for
multiple algorithms(like MRT_blue and MRT_red)Š

Does it not look sensible? I think we are making this request in the
interest of all those who also wants to do MRT with SPRING (instead of
LDP)Š I request you all to reconsider this.

Thanks
-Pushpasis

On 3/30/15, 7:58 PM, "Ahmed Bashandy" <[e-mail]> wrote:

>I think the primary purpose of this email thread is to seek the opinion
>of the community on the very minor changes that Stefano proposed. If
>there is a feeling that other modifications are necessary or desirable,
>then a different email thread would avoid an ever growing discussion
>
>Ahmed
>
>
>On 3/27/2015 6:22 AM, Chris Bowers 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