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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Pushpasis -

(Your mailer continues to insert the "bounce" alias for the WG instead of the WG address - please see if you can fix this as it means your posts won't be sent to the list. I have corrected this in my reply.)

As outlined in my post, the changes being requested are NOT minimal. They make  fundamental changes in the way SRGBs are defined/used - and have implications in the way routers implement local label allocation.

Given there is a strong desire to minimize backwards compatibility issues (publicly expressed by multiple people) it is hard for me to understand how you can suggest that now it is OK to introduce a much more disruptive change. Further, this change is NOT essential to support the use case you have in mind. 

   Les

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Pushpasis
> Sarkar
> Sent: Tuesday, March 31, 2015 10:50 AM
> To: Ahmed Bashandy (bashandy); Chris Bowers; [e-mail] list
> Cc: Stefano Previdi (sprevidi); draft-ietf-isis-segment-routing-
> [e-mail]
> Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-
> extensions
> 
> 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
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg