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

[Uma Chunduri <[e-mail]>]

Hi Hannes,

> don't you have concerns that fragment-0 might get a too crowded space ?

Of course it could  be crowded but when I sent the mail I was just thinking on how can we ensure 
SRGB always if it is indeed provisioned on a node   in "all" situations (shrinking/HA cases for a particular node etc..). 

As we agree, unlike any other TLV/Prefix the impact of not having this in transient cases can cause complete label 
withdrawals on all receiving nodes and  have lot of impact/churn  on end-to-end LSPs using these labels.

If not fragment-0 make it mandatory to have the required stickiness (as you indicated) in the same fragment.  
Probably adding more text clarifying this would be better

Hi Les,

> This is a wise policy and we should not change it just because it seems "convenient" to find a particular bit of information.

Perhaps "wise" but as explained above this is not about "convenience" rather avoiding potential transient loops and churn as this is a "critical" piece 
of information like area ID example you gave!

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
Sent: Thursday, March 26, 2015 5:02 PM
To: Hannes Gredler; Uma Chunduri
Cc: [e-mail] list; Stefano Previdi (sprevidi); [e-mail]
Subject: RE: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

(Hannes beat me to it! :-) )

Restricting TLVs to LSP #0 is a BAD IDEA!!

The only think special about LSP #0 is that it is required to be present in order to make use of any other LSP generated by the same system. The protocol has historically not imposed restricting TLVs to LSP #0 except in some very special cases (e.g. area addresses). This is a wise policy and we should not change it just because it seems "convenient" to find a particular bit of information.

   Les
'

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Hannes 
> Gredler
> Sent: Thursday, March 26, 2015 2:37 PM
> To: Uma Chunduri
> Cc: [e-mail] list; Stefano Previdi (sprevidi); 
> draft-ietf-isis-segment- [e-mail]
> Subject: Re: [Isis-wg] Proposed Changes in 
> draft-ietf-isis-segment-routing- extensions
> 
> hi uma,
> 
> don't you have concerns that fragment-0 might get a too crowded space ?
> 
> /hannes
> 
> On Thu, Mar 26, 2015 at 07:34:51PM +0000, Uma Chunduri wrote:
> | Dear Stefano and authors,
> |
> | Proposed modifications (though not exact text)  are very thoughtful 
> | and IMO this is really good and I don't see any backward 
> | compatibility issues (I didn't see many vendors yet advertise multiple SRGBs).
> |
> |  >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).
> |
> | "SAME" ==> fragment-0 perhaps this would ensure SRGB is ALWAYS there 
> | (as this is critical for SR to even begin)  in the same fragment 
> | regardless on non-zero fragments have any data which are and can 
> | change,
> shrink etc.. (may be it could be too restrictive, but if this is to be 
> considered this is the best time)?
> |
> | And I have posted my comments earlier on flags to be changed to 
> | MT-ID and yet to see response and changes surrounding the same.
> |
> | --
> | Uma C.
> |
> | -----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