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

[Ahmed Bashandy <[e-mail]>]

Hi Pushpasis

*In this email thread*, I am not discussing the sensibility, 
appropriateness, size, impact,..., etc of the other suggestions. I want 
to reach conclusion on the matter under discussion.

If someone feels that there is a need for other modifications 
(irrespective of the his/her assessment of the impact of these other 
modifications), then a separate email thread is more appropriate to be 
able to close on the modifications proposed in this email thread

Ahmed

On 3/31/2015 10:50 AM, Pushpasis Sarkar wrote:
> 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