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

[Hannes Gredler <[e-mail]>]

hi stefano,

On Sun, Mar 29, 2015 at 10:06:08PM +0000, Stefano Previdi (sprevidi) wrote:
| 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.
| 

have spoken to chris offline - what he wants to do is add the algo-ID to the SRGB.

  my understanding is that this is required for resilient packet-rings in the access
  which have very constrained MPLS stacking capabilities (and R-LFA with its two labels
  blows the stacking budget and MRT single label does not) ...

The change is not as radical as it sounds -
"if an implementation does not support a non-zero algo-ID then it MUST ignore the SRGB"

and

"Every implementation MUST support the SRGBs with algo-id of zero"

/hannes

| On Mar 27, 2015, at 2:33 PM, Pushpasis Sarkar <[e-mail]> 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" <[e-mail]> 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