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

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

I agree with this approach, since this is the best path forward given the current implementations




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