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

[Jeff Tantsura <[e-mail]>]

Fully support the changes proposed.

Regards,
Jeff

> 
> 
>> On 25/03/15 12:42, "Stefano Previdi (sprevidi)" <[e-mail]> wrote:
>> 
>> 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