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

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.

s.

On Mar 27, 2015, at 2:33 PM, Pushpasis Sarkar <psarkar@juniper.net> 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" <cbowers@juniper.net> 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:isis-wg-bounces@ietf.org] On Behalf Of Stefano
>> Previdi (sprevidi)
>> Sent: Wednesday, March 25, 2015 6:42 AM
>> To: isis-wg@ietf.org list
>> Cc: draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> 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
>> Isis-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
>> 
>> _______________________________________________
>> Isis-wg mailing list
>> Isis-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
> 