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

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

Uma -

The base protocol  specification (ISO 10589) stipulates that an implementation should refrain from moving information from one LSP to another whenever possible. This applies to ALL information advertised by IS-IS - it does not need to be repeated for any particular TLV/sub-TLV.

   Les

> -----Original Message-----
> From: Uma Chunduri [mailto:[e-mail]]
> Sent: Friday, March 27, 2015 9:57 AM
> To: Les Ginsberg (ginsberg); Hannes Gredler
> 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 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); draft-ietf-isis-segment-
> [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