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

[Uma Chunduri <[e-mail]>]

Again, absolutely no issues for me if this is understood and already factored!

--
Uma C.


-----Original Message-----
From: Isis-wg [mailto:[e-mail]] On Behalf Of Uma Chunduri
Sent: Friday, March 27, 2015 12:28 PM
To: Les Ginsberg (ginsberg); Hannes Gredler
Cc: [e-mail] list; Stefano Previdi (sprevidi); [e-mail]
Subject: Re: [Isis-wg] Proposed Changes in draft-ietf-isis-segment-routing-extensions

Of course!

..and we know  and see how this is being followed/not followed practically in some cases in actual deployments (and the impact may or may not be even noticed if it is really transient and for few prefixes) .

Again my only point was this not "any" information!

--
Uma C.


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

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

_______________________________________________
Isis-wg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/isis-wg