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

[Hannes Gredler <[e-mail]>]

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