Hi Naiming, Yes, my point is that reverse-metric values 2^24-2 and 2^24-1 are special-purpose values for which operation “set” should be applied rather than “add”. For other values (below 2^24-2) operation “add” is performed with the rule ‘min(sum, 2^24-2)’.
Thank you. Best regards, Alexander Okonnikov 18 янв. 2018 г., 21:30 +0300, Naiming Shen (naiming) <[email protected]>, писал: > > Hi Alexander, > > As mentioned, the ‘reverse-metric’ is an ‘Offset metric’, and it’s > accumulative on the receiving > end. So when you send (2^24-2) over, unless the other side is configured on > interface of > IS-IS metric of zero (which is the case on Pnode), then you are not going to > deterministically > for the case of (2^24-2) vs (2^24-1) as a result. The ‘U’ bit is for setting > that top limit for neighbor. > Thus in the mobility use case, without knowing the other side configured > metric, this side > can do ‘1’, ‘2’, ‘etc’ to gradually increase the “inbound” metric towards > itself. > > If this were an ‘absolute’ value for the other side to install regardless of > their configured metric, > then you are right. > > thanks. > - Naiming > > > On Jan 18, 2018, at 1:50 AM, Alexander Okonnikov > > <[email protected]> wrote: > > > > Hi Naiming, > > > > For signaling unreachability of the link to ISs outside that link we don't > > need utilize U-bit in IIH. When receiving IS observes that IGP or TE > > reverse metric is 2^24-1, it sets its operational forward metric to 2^24-1 > > as well and signals it in its LSP, without redundant signaling via U-bit in > > received IIH. As a consequence, other ISs become aware about unreachability > > of the link (in fact about unreachability of the link for IGP and TE > > topologies). This is the same I proposed to do without U-bit. One detail > > about U-bit I am confused is that U-bit signals that both metrics (IGP and > > TE) should be maximized, irrespectively to values of metrics in Offset > > field and in TE Default Metric Sub-TLV (the latter may not be present at > > all). > > > > This is not needed to allocate new bit to signal that metric value must not > > exceed 2^24-1. Values of both kinds of metric are signaled using 24-bit > > fields in LSP, so it is not possible to advertise values greater than > > 2^24-1. If sum of forward + reverse metric is greater than 2^24-1, it > > should be set by receiver to 2^24-1, like it is being done for 'last > > resort' mode, described in section 3.1, where metric value must not be > > greater than 2^24-2. > > > > Follow is my proposal in examples without U-bit: > > > > 1. Originator wishes to make link last resort for IGP, but not TE: > > > > Originator sets Metric Offset value to 2^24-2. TE reverse metric is not > > advertised or advertised with value 0. > > Receiver sets its IGP metric to 2^24-2 (even if its IGP forward metric is > > >=1). Receiver's TE metric is not modified. > > > > 2. Originator wishes to make link last resort for TE, but not IGP: > > > > Originator sets TE reverse metric to 2^24-2. Metric Offset value is 0. > > Receiver sets its TE metric to 2^24-2 (even if its TE forward metric is > > >=1). Receiver's IGP metric is not modified. > > > > 3. Originator wishes to make link last resort for both IGP and TE: > > > > Originator sets Metric Offset and TE metric values to 2^24-2. > > Receiver sets its IGP and TE metrics to 2^24-2 (even if its IGP and TE > > forward metrics are >=1). > > > > 4. Originator wishes to make link unreachable for IGP, but not TE: > > > > Originator sets Metric Offset value to 2^24-1. TE reverse metric is not > > advertised or advertised with value 0. > > Receiver sets its IGP metric to 2^24-1 (irrespectively to its IGP forward > > metric). Receiver's TE metric is not modified. > > > > 5. Originator wishes to make link unreachable for TE, but not IGP: > > > > Originator sets TE reverse metric to 2^24-1. Metric Offset value is 0. > > Receiver sets its TE metric to 2^24-1 (irrespectively to its TE forward > > metric). Receiver's IGP metric is not modified. > > > > 6. Originator wishes to make link unreachable for both IGP and TE: > > > > Originator sets Metric Offset and TE metric values to 2^24-1. > > Receiver sets its IGP and TE metrics to 2^24-1 (irrespectively to its IGP > > and TE forward metrics). > > Thank you. > > > > 16.01.2018 09:46, Naiming Shen (naiming) пишет: > > > > > > Hi Alexander, > > > > > > The reason we share that ‘U' bit, first of all, this is a bit on the > > > link, not in LSP, > > > unless the LSP propagates the meaning, no one outside knows about that. > > > So, it is important to have the neighbor to raise the metric for both IGP > > > and TE > > > to indicate something for both metric. > > > 2nd, the ‘U’-bit just indicate the max can be upto 2^24-1. if the > > > accumulated > > > metric of configured plus the ‘reverse’ is >= 2^24-1. If one wants to have > > > one is usable and the other is unusable, that is easy, send in > > > ‘reverse-metric' TLV > > > for the normal metric to be zero, and the ‘reverse-metric’ TE sub-TLV > > > metric > > > to be ‘2^24-1’, that will achevie exact the effect, and set the ‘U’ bit. > > > The other way around is also the same. > > > > > > thanks. > > > - Naiming > > > > > > > On Jan 15, 2018, at 10:21 PM, Alexander Okonnikov > > > > <[email protected]> wrote: > > > > > > > > Hi Naiming, Les, Chris, > > > > > > > > Version -08 specifies new U-bit to be used simultaneously both for IGP > > > > and TE metrics. It seems to be suboptimal. What if the goal is to > > > > modify IGP link properties while left TE link properties intact? U-bit > > > > set says that both - IGP and TE metrics - should be maximized on > > > > receiving IS. From CSPF perspective there is no much difference between > > > > TE metrics 2^24-2 and 2^24-1 - they are both indicate ‘last resort’ but > > > > still ‘usable’ link. For TE metric manipulation we have reverse TE > > > > Default Metric Sub-TLV and don’t need U-bit. For making IGP link > > > > unusable we have special reverse-metric value 2^24-1 and don’t need > > > > U-bit as well. If the draft will state that TE metric 2^24-1 should > > > > indicate TE link as unusable (from CSPF perspective), reverse TE metric > > > > 2^24-1 could be specified as special value for this like it is > > > > specified for IGP link. > > > > > > > > Thanks. > > > > > > > > Best regards, > > > > Alexander Okonnikov > > > > > > > > 11 янв. 2018 г., 23:45 +0300, Les Ginsberg (ginsberg) > > > > <[email protected]>, писал: > > > > > I agree with Naiming on these changes. > > > > > > > > > > Originally I was opposed to the use of max_metric-1 by reverse metric > > > > > as with the new bit defined in link attributes there was no need. But > > > > > Naiming has pointed out that in order for the new link attribute bit > > > > > to be effective all routers have to be upgraded to support it. His > > > > > proposal of being able to optionally set max_metric-1 means that even > > > > > routers who do not support reverse_metric will avoid the link in > > > > > question simply because they will respond to the large advertised > > > > > metric at both ends of the link. > > > > > > > > > > Allowing max_metric-1 means the link can be completely removed from > > > > > the IGP topology in both directions in a backwards compatible way. > > > > > While max_metric-1 is NOT defined as "do not use" for the TE > > > > > topology, it does make the link very unattractive to any C-SPF which > > > > > considers metric - and so achieves what is desired - again in a > > > > > backwards compatible way. > > > > > > > > > > I think this is a significant improvement. > > > > > > > > > > Many thanks to Naiming for realizing all of the downsides of using > > > > > the new link attribute bit. > > > > > > > > > > Les > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Naiming Shen (naiming) > > > > > > Sent: Thursday, January 11, 2018 12:20 PM > > > > > > To: Christian Hopps <[email protected] > > > > > > Cc: Les Ginsberg (ginsberg) <[email protected]>; [email protected]; > > > > > > isis- > > > > > > [email protected] > > > > > > Subject: Re: [Isis-wg] WG Last Call for > > > > > > draft-ietf-isis-reverse-metric-07 > > > > > > > > > > > > > > > > > > Hi Chris, > > > > > > > > > > > > > On Jan 11, 2018, at 1:19 AM, Christian Hopps <[email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Naiming Shen (naiming) <[email protected]> writes: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Sounds reasonable. At this stage of the draft, we’ll probably > > > > > > > > skip > > > > > > > > this capability. If it is found needed later, it can be added > > > > > > > > easily. > > > > > > > > I suspect there are a number of other things can be later ride > > > > > > > > on top of > > > > > > this. > > > > > > > > > > > > > > Hi Naiming, > > > > > > > > > > > > > > Correct me if I'm wrong, but aren't you saying here that you > > > > > > > would not > > > > > > > add the 2^24-1 functionality? I'm asking b/c you also just > > > > > > > published a > > > > > > > new version -08 that appears to add this functionality. :) > > > > > > > > > > > > > > Was there any off-list discussion that led to the change of heart? > > > > > > > > > > > > Actually, this is not really a new functionality of the draft:-) We > > > > > > also removed > > > > > > the section 3.6 “Link Overload Attribute Bit” of sub-TLV of TLV 22 > > > > > > in the LSP. > > > > > > This change is due to several factors: > > > > > > > > > > > > - the long discusion ongoing of OSPF mailing list of the name > > > > > > “overload”, > > > > > > which has disagreement on what does this “overload” really meant, > > > > > > and > > > > > > what to do if it’s “overloaded”. This version 7 borrowed this from > > > > > > OSPF, and > > > > > > now we got requests also to reconsider the name of this “Link > > > > > > Overload > > > > > > Attribute Bit” > > > > > > > > > > > > - More importantly we just realized that, to use this “overload” > > > > > > bit in LSP, the > > > > > > backwards compatibility is not possible anymore, as in the other > > > > > > “reverse- > > > > > > metric” feature which is all local to the link. So, if we have to > > > > > > use this > > > > > > “overload” bit in LSP, we have also to define the router > > > > > > “capabilities” to > > > > > > advertise this, and synchronize among area/domain, which we really > > > > > > don’t > > > > > > want to do in ‘reverse-metric' > > > > > > > > > > > > - Third with this “U” bit, it achieves the same effect of the > > > > > > “overload” bit, > > > > > > since the neighbor can optionally set the (2^24-1) and take out the > > > > > > link as > > > > > > ‘unusable’ for IGP or TE, while at the mean time keep the same > > > > > > backwards > > > > > > compatibility in the area/domain, which is a very clean solution. > > > > > > > > > > > > - I have had long email/chat discussion on this with Les, since we > > > > > > have seen > > > > > > the email, this (2^24-1) has been part of the comments discussion > > > > > > during the > > > > > > last call. and at the time I didn’t think clearly and mentioned on > > > > > > the list we > > > > > > wouldn't do that, but with all the above mentioned reasons, we > > > > > > decided that > > > > > > is the right way to go. As mentioned, the reason of doing that is > > > > > > not to handle > > > > > > the multi-area LDP/IGP sync kind of use-case, but to support TE > > > > > > topology to > > > > > > take the link out just as in the removed section 3.6 in ver 7. > > > > > > > > > > > > thanks. > > > > > > - Naiming > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Chris. > > > > > > > > > > > > > > > Regards, > > > > > > > > - Naiming > > > > > > > > > > > > > > > > On Dec 30, 2017, at 4:05 PM, Les Ginsberg (ginsberg) > > > > > > <[email protected]<mailto:[email protected]>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Alexander Okonnikov [mailto:[email protected]] > > > > > > > > Sent: Saturday, December 30, 2017 3:34 PM > > > > > > > > To: Les Ginsberg (ginsberg) > > > > > > > > <[email protected]<mailto:[email protected] > > > > > > > > Cc: Naiming Shen (naiming) > > > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > > > [email protected]<mailto:[email protected]>; Christian Hopps > > > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > > > [email protected]<mailto:[email protected] > > > > > > > > Subject: Re: [Isis-wg] WG Last Call for > > > > > > > > draft-ietf-isis-reverse-metric-07 > > > > > > > > > > > > > > > > Les, > > > > > > > > > > > > > > > > > > > > > > > > 31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg) > > > > > > <[email protected]<mailto:[email protected]>> написал(а): > > > > > > > > > > > > > > > > Alex - > > > > > > > > > > > > > > > > From: Alexander Okonnikov [mailto:[email protected]] > > > > > > > > Sent: Saturday, December 30, 2017 3:06 PM > > > > > > > > To: Les Ginsberg (ginsberg) > > > > > > > > <[email protected]<mailto:[email protected] > > > > > > > > Cc: Naiming Shen (naiming) > > > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > > > [email protected]<mailto:[email protected]>; Christian Hopps > > > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > > > [email protected]<mailto:[email protected] > > > > > > > > Subject: Re: [Isis-wg] WG Last Call for > > > > > > > > draft-ietf-isis-reverse-metric-07 > > > > > > > > > > > > > > > > Les, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg) > > > > > > <[email protected]<mailto:[email protected]>> написал(а): > > > > > > > > > > > > > > > > Alex - > > > > > > > > > > > > > > > > From: Alexander Okonnikov [mailto:[email protected]] > > > > > > > > Sent: Saturday, December 30, 2017 2:38 PM > > > > > > > > To: Les Ginsberg (ginsberg) > > > > > > > > <[email protected]<mailto:[email protected] > > > > > > > > Cc: Naiming Shen (naiming) > > > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > > > [email protected]<mailto:[email protected]>; Christian Hopps > > > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > > > [email protected]<mailto:[email protected] > > > > > > > > Subject: Re: [Isis-wg] WG Last Call for > > > > > > > > draft-ietf-isis-reverse-metric-07 > > > > > > > > > > > > > > > > Hi Les, > > > > > > > > > > > > > > > > Don't advertise link and advertise it with metric 2^24-1 makes > > > > > > > > sense again. > > > > > > In the former case that link cannot be used for TE LSPs, while in > > > > > > latter one it is > > > > > > possible. This is also described in RFC 5305: > > > > > > > > > > > > > > > > " If a link is advertised with the maximum link metric (2^24 - > > > > > > > > 1), this > > > > > > > > link MUST NOT be considered during the normal SPF computation. > > > > > > > > This > > > > > > > > will allow advertisement of a link for purposes other than > > > > > > > > building > > > > > > > > the normal Shortest Path Tree. An example is a link that is > > > > > > > > available for traffic engineering, but not for hop-by-hop > > > > > > > > routing." > > > > > > > > > > > > > > > > [Les:] I am well aware of this. My comment regarding (2^24 - 1) > > > > > > > > is in the > > > > > > context of reverse metric. If the reason that you want to advertise > > > > > > (2^24-1) is > > > > > > because the link is only supposed to be used for TE purposes then > > > > > > this would > > > > > > already have been done by the neighbor as part of their > > > > > > configuration – and > > > > > > it has nothing to do with adjacency bringup. > > > > > > > > Idea was to temporarily disable IP forwarding on the link while > > > > > > > > preserve > > > > > > ability to use link for other transport. An example when we need it > > > > > > - IGP-LDP > > > > > > sync. If you configure 2^24-1 on the neighbor, then link will be > > > > > > excluded from > > > > > > IP topology permanently. Also, it is not clear for me how it could > > > > > > be done on > > > > > > LAN. > > > > > > > > > > > > > > > > > > > > > > > > [Les:] My point is – if you do not want the link to be used at > > > > > > > > all – even if > > > > > > only while waiting for LDP sync to complete – then you simply don’t > > > > > > advertise > > > > > > the adjacency. In the case of the LAN you don’t advertise the > > > > > > adjacency to > > > > > > the DIS – so there is no 2-way connectivity on that circuit and no > > > > > > traffic flows > > > > > > to/from the node via the interface in question. It does not matter > > > > > > what the > > > > > > neighbor/DIS is advertising. > > > > > > > > My point - to have ability to exclude link from IP topology, > > > > > > > > but still use it in > > > > > > other topologies. This could be done by advertising metric 2^24-1. > > > > > > If > > > > > > adjacency is not advertised, then that link is excluded from all > > > > > > topologies, not > > > > > > only from IP. In general my proposal is to make reverse-metric > > > > > > functionality > > > > > > as flexible as possible and to don't restrict it deliberately. > > > > > > > > > > > > > > > > [Les:] This is exactly what I object to. Reverse-metric is not > > > > > > > > and should not > > > > > > be a general purpose mechanism to have one node override the > > > > > > configuration of its neighbors for any and all possible reasons. It > > > > > > has well > > > > > > defined use cases which the draft describes and its use should be > > > > > > limited to > > > > > > those cases. > > > > > > > > > > > > > > > > The additional use cases you have suggested can already be > > > > > > > > handled by > > > > > > existing mechanisms which are local to each node and that should > > > > > > always be > > > > > > the preferred means. The potential for chaos that results when each > > > > > > node > > > > > > utilizes this mechanism to adjust the SPF outcome on other routers > > > > > > based on > > > > > > its local view of the current state of convergence is not something > > > > > > I want to > > > > > > embrace. > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding L1 circuit between L1/L2 routers - it is not always > > > > > > > > possible or is > > > > > > not desired. > > > > > > > > > > > > > > > > [Les:] I was covering the example you provided. It was clear > > > > > > > > from your > > > > > > example that although L2 only was enabled between the L1/L2 > > > > > > routers, you > > > > > > were allowing intra-area traffic to flow over that link. > > > > > > > > If you do not want intra-area traffic to flow over that link at > > > > > > > > all, then you > > > > > > need to insure that L1 destinations are not leaked into L2 – in > > > > > > which case the > > > > > > proposed change you are suggesting for reverse-metric would not > > > > > > help. > > > > > > > > > > > > > > > > If you think you have a different example that justifies your > > > > > > > > proposal I > > > > > > would be happy to review it – but the one you have come up with > > > > > > isn’t > > > > > > compelling. > > > > > > > > Two L1/L2 routers could be geographically dispersed. > > > > > > > > [Les:] Only if the L1/L2 routers are in different areas – in > > > > > > > > which case your > > > > > > example does not apply. > > > > > > > > Not necessary. There could be area represented by sub-ring > > > > > > > > physical > > > > > > topology. > > > > > > > > > > > > > > > > > > > > > > > > There could be L2 subdomain which provides L2 path between > > > > > > > > them. But > > > > > > sometimes it is not optimal to configure L1/L2 on all transit L2 > > > > > > routers > > > > > > between two ones. Also, for redundancy you will need to provide > > > > > > alternative > > > > > > L1 path in the core (to avoid routing traffic via access). > > > > > > > > > > > > > > > > Another case, when having looped L1 is not desired - when R3 has > > > > > > reachability to the network via two ABRs (R1 and R2), and R2 is > > > > > > closer to R3 > > > > > > than R1 to R3. In case link (path) from R3 to R2 is broken, it is > > > > > > more optimal > > > > > > from data path perspective to reroute traffic to R1 rather than to > > > > > > R2 via R1. It > > > > > > is not case for regular IP routing, but becomes sensitive when we > > > > > > have deal > > > > > > with L2VPN services, such that MS-PW or H-VPLS, where R1 and R2 are > > > > > > S-PEs > > > > > > or Hub PEs, respectively. > > > > > > > > > > > > > > > > [Les:] We are not discussing all possible network topologies. > > > > > > > > The topic > > > > > > here is the Reverse-Metric draft and whether there is a use case > > > > > > for a node > > > > > > to tell its neighbor to advertise max-metric (2^24-1). > > > > > > > > Please stay on topic. If you have an example that justifies > > > > > > > > your proposal I > > > > > > would like to hear it – but please stay focused on this use case. > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg) > > > > > > <[email protected]<mailto:[email protected]>> написал(а): > > > > > > > > > > > > > > > > I strongly disagree with this proposed change. > > > > > > > > > > > > > > > > If you want to take the link totally out of the topology then > > > > > > > > simply don’t > > > > > > advertise the adjacency. This works for both P2P and LAN cases. > > > > > > > > This is why the draft states > > > > > > > > > > > > > > > > “a receiver of a > > > > > > > > Reverse Metric TLV MUST use the numerically smallest value of > > > > > > > > either > > > > > > > > the sum of its existing default metric and the Metric Offset > > > > > > > > value in > > > > > > > > the Reverse Metric TLV or (2^24 - 2)” > > > > > > > > > > > > > > > > There is no use case for (2^24 - 1). > > > > > > > > > > > > > > > > As for the L1/L2 example topology that Alex used to justify his > > > > > > > > proposal, > > > > > > there is a much better way to prevent the premature use of the L1 > > > > > > link. That > > > > > > is to enable L1 on the link between the two L1L2 routers but > > > > > > configure a > > > > > > larger metric (e.g. 100000) so that the L1/L2 link will only be > > > > > > used for L1 traffic > > > > > > when there is no viable L1 only link. There is no need to use > > > > > > Reverse-Metric > > > > > > to do so and I believe this is an inappropriate use of this > > > > > > extension. > > > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > > > > > From: Isis-wg [mailto:[email protected]] On Behalf Of > > > > > > > > Naiming > > > > > > > > Shen (naiming) > > > > > > > > Sent: Saturday, December 30, 2017 11:59 AM > > > > > > > > To: Alexander Okonnikov > > > > > > > > > > > > > > <[email protected]<mailto:[email protected] > > > > > > > > > > > > > > > > Cc: [email protected]<mailto:[email protected]>; Christian Hopps > > > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > > > [email protected]<mailto:[email protected] > > > > > > > > Subject: Re: [Isis-wg] WG Last Call for > > > > > > > > draft-ietf-isis-reverse-metric-07 > > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > Ok. We’ll add a bit to the flag (the 2nd bit) of the > > > > > > > > ‘reverse-metric > > > > > > > > TLV’, to indicate the originator requesting the inbound > > > > > > > > direction of > > > > > > > > the link not to be used and the metric should be raised by the > > > > > > > > peer to > > > > > > (2^24 - 1) regardless the value of the ‘offset metric’ > > > > > > > > value in the TLV. > > > > > > > > > > > > > > > > thanks. > > > > > > > > - Naiming > > > > > > > > > > > > > > > > On Dec 29, 2017, at 11:46 AM, Alexander Okonnikov > > > > > > <[email protected]<mailto:[email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Naiming, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 29 дек. 2017 г., в 6:10, Naiming Shen (naiming) > > > > > > <[email protected]<mailto:[email protected]>> написал(а): > > > > > > > > > > > > > > > > > > > > > > > > Hi Alexander, > > > > > > > > > > > > > > > > Thanks for the comments, see more replies inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov > > > > > > <[email protected]<mailto:[email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi authors, > > > > > > > > > > > > > > > > > > > > > > > > I have some comments below regarding the draft: > > > > > > > > > > > > > > > > > > > > > > > > 1) Section 2: "There is currently only two Flag bits defined." > > > > > > > > Per -07 only > > > > > > one flag is defined. S flag was deprecated since version -06 > > > > > > (implicit signaling > > > > > > of presence of Sub-TLVs is used via "Sub-TLV Len" field non-zero > > > > > > value. Text > > > > > > in the beginning of the chapter 2 about flag S is to be removed as > > > > > > well. > > > > > > > > > > > > > > > > NS> will fix. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) Section 3.1: "In order to ensure that an individual TE link > > > > > > > > is used as a link > > > > > > of last resort during SPF computation, ..." I guess that you meant > > > > > > regular link > > > > > > rather than TE link. > > > > > > > > > > > > > > > > 3) For the same section: Per my understanding, this section > > > > > > > > assumes that > > > > > > overloaded link will always be considered as last-resort link. I.e. > > > > > > it cannot be > > > > > > excluded from topology (as link with metric 2^24-1), unless > > > > > > originator of the > > > > > > TLV sets appropriate bit in corresponding Link Attributes Sub-TLV > > > > > > (RFC 5029) > > > > > > AND receiving ISs support that Sub-TLV. As alternative it could be > > > > > > done by > > > > > > allowing for originator to specify reverse metric special value > > > > > > 2^24-1 which > > > > > > would indicate to receivers that the link is to be excluded from > > > > > > topology > > > > > > completely rather than used as last resort. If reverse metric value > > > > > > is between > > > > > > 0 - 2^24-2 then link could be used in path calculation. The same > > > > > > rules for TE > > > > > > metric. > > > > > > > > > > > > > > > > > > > > > > > > NS> I don’t see there is much difference between not used or > > > > > > > > last resort > > > > > > in the use cases we mentioned. > > > > > > > > also, this metric value is an ‘offset metric’ being added on > > > > > > > > top of > > > > > > > > the existing local metric. It would not be always feasible to > > > > > > > > make the > > > > > > reverse-metric off by one to mean two completely different > > > > > > operations. > > > > > > > > > > > > > > > > One use case when unusable link vs last resort one makes sense > > > > > > > > is for > > > > > > > > IGP-LDP sync. Let's assume we have two-level IS-IS domain. > > > > > > > > There are > > > > > > > > three ISs in the domain: R1 and R2 are L1/L2 ISs, and R3 is > > > > > > > > L1-only. > > > > > > > > R1 and R2 are connected to each other via L2 circuit, and R3 is > > > > > > > > connected to R1 and R2 via L1 circuits. The link between R2 and > > > > > > > > R3 > > > > > > > > was broken and now is being restored. While adjacency has not > > > > > > > > been > > > > > > > > established on failed link, R3 has inter-area route towards R2's > > > > > > > > loopback. Once adjacency has been established, but LDP session > > > > > > > > has > > > > > > > > not yet, R3 and R2 maximize metric (2^24-2) on corresponding > > > > > > > > link. > > > > > > > > But now R2 and R3 have routes to each other as L1 intra-area, > > > > > > > > though > > > > > > > > with max metric. Because L1 intra-area route wins, R2 and R3 > > > > > > > > replace > > > > > > > > inter-area routes to each other by intra-area ones. As a > > > > > > > > result, LDP > > > > > > > > LSPs are blackholed. On the other hand, if two routers mark > > > > > > > > corresponding link as unusable (with metric 2^24-1), they would > > > > > > > > use > > > > > > > > inter-area routes until IGP-LDP sync will be com > > > > > > > pleted. > > > > > > > > > > > > > > > > An IS can make decision on whether to mark link as unusable or > > > > > > > > as last > > > > > > resort, using the same principle as proposed in RFC 6138. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4) For the same section: The draft says that if originator uses > > > > > > > > narrow > > > > > > metric-type, it should use value 63 as max-metric. But on receiving > > > > > > reverse > > > > > > metric with such value receivers have no idea whether this is > > > > > > "narrow" max- > > > > > > metric or offset 63 for "wide" metric. I.e. the draft assumes that > > > > > > all ISs use > > > > > > the same type of metric, and using of two metric types at the same > > > > > > time is > > > > > > not covered. May be it would be appropriate to define two Reverse > > > > > > Metric > > > > > > TLVs, like IS Neighbors TLV and Extended IS Reachability TLV. Or to > > > > > > specify > > > > > > new flag to mark type of the reverse metric. > > > > > > > > > > > > > > > > > > > > > > > > NS> to be simple, we have to assume a network is either run > > > > > > > > wide or > > > > > > > > NS> narrow. It can not be fixed. The > > > > > > > > document is trying to be complete to mention the ‘narrow’ case. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5) For the same section: It is not clear for me why DIS should > > > > > > > > use min(63, > > > > > > (Metric + Reverse Metric)) while composing pseudonode LSP. If DIS is > > > > > > configured for using "wide" metric-type, it will use Extended IS > > > > > > Reachability > > > > > > TLVs for describing its neighbors. Moreover, in this case DIS is > > > > > > not obligated > > > > > > to still insert IS Neighbors TLVs in its Pseudonode LSP (in > > > > > > addition to > > > > > > Extended IS Reachability TLVs) when it is configured for > > > > > > "wide-only" mode. > > > > > > > > > > > > > > > > NS> agreed. will remove this, to keep the same goal as above, > > > > > > > > to be > > > > > > simple. Not to mix them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 6) For the same section: It is not clear for me why in case > > > > > > > > when TE metric > > > > > > offset is not advertised in Reverse Metric TLV, receiving IS must > > > > > > modify its TE > > > > > > metric by adding IGP reverse metric value. In my mind, it would be > > > > > > straightforward to use follow rule: if originator doesn't include > > > > > > TE metric part > > > > > > then it doesn't wish to overload TE link, but only IGP link. For > > > > > > example, > > > > > > originator advertises Reverse metric TLV as part of IGP-LDP > > > > > > synchronization > > > > > > procedure (section 3.5). It is not reason to impact TE properties > > > > > > (metric in this > > > > > > case) of the link. Hence, originator could advertise Reverse metric > > > > > > TLV > > > > > > without TE metric Sub-TLV, in order to signal that "TE metric is > > > > > > left intact”. > > > > > > > > > > > > > > > > NS> sounds resonable. Will change this to say if the sub-TLV of > > > > > > > > TE is > > > > > > > > NS> not received, the TE properties will not change > > > > > > > > by receiving this ‘reverse-metric’ TLV. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 7) Section 3.3: The draft is not clear about handling of TE > > > > > > > > metric by DIS. > > > > > > Usually DIS implementations don't insert TE Sub-TLVs into Extended > > > > > > IS > > > > > > Reachability TLVs in Pseudonode LSP. May be it would be better to > > > > > > add > > > > > > explicit text that: if DIS receives TE metric Sub-TLV in Reverse > > > > > > Metric TLV it > > > > > > should update TE Default Metric Sub-TLV value of corresponding > > > > > > Extended IS > > > > > > Reachability TLV OR insert new one if it was not present there. > > > > > > > > > > > > > > > > NS> To me, there is not much difference between DIS and other > > > > > > > > nodes. > > > > > > Will try to add some words to that. > > > > > > > > > > > > > > > > thanks. > > > > > > > > - Naiming > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > 30.11.2017 01:47, Naiming Shen (naiming) пишет: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ketan, > > > > > > > > > > > > > > > > thanks for the support and comments. some clarification inline, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) > > > > > > <[email protected]<mailto:[email protected]>> wrote: > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > I support this draft, however would like the following > > > > > > > > aspect/scenario > > > > > > clarified. > > > > > > > > > > > > > > > > Consider the scenario where both the neighbours on a p2p link > > > > > > > > initiate the > > > > > > reverse metric procedure (i.e. include the TLV in their hellos > > > > > > concurrently). > > > > > > How are implementations supposed to handle this? Normally the > > > > > > choice of > > > > > > metric conveyed via this TLV is based on a particular condition > > > > > > (which need > > > > > > not just be "overload") on the local router which requires the > > > > > > neighbour to > > > > > > use shift to using the reverse metric supplied. So when both > > > > > > neighbours > > > > > > initiate this process, it would be good to have the specification > > > > > > provide a > > > > > > deterministic behaviour since the reverse metric values provided may > > > > > > conflict in certain "non-overload" conditions. If both routers > > > > > > simply accept > > > > > > the value supplied by their neighbour, it may not achieve the > > > > > > original > > > > > > purpose/design of this triggering this mechanism? > > > > > > > > When you say if both sides initiated this ‘reverse metric’, you > > > > > > > > implied there is a timing issue with this procedure in the > > > > > > > > draft. > > > > > > > > > > > > > > > > The value of this ‘metric offset’ (or whatever will be called) > > > > > > > > of > > > > > > > > this TLV, is just a number. The draft does not say this number > > > > > > > > is > > > > > > > > equal to the configured ‘metric’ value plus the received > > > > > > > > ‘reverse > > > > > > > > metrc’ value, that would be non-deterministic and both sides > > > > > > > > would > > > > > > > > keep going up until it’s > > > > > > > > overloaded:-) > > > > > > > > > > > > > > > > Each side of IS-IS link decides if it needs to send a ‘reverse > > > > > > > > metric’ over the link, either in link-overloading case, or other > > > > > > > > cases. It’s a static number, it does not depend on the other > > > > > > > > side > > > > > > > > sending a ‘reverse metric’ or not. This both sides sending a > > > > > > > > ‘reverse-metric’ over a link is equivalent to an operator > > > > > > > > provisions > > > > > > > > new metric (say both plus 10 to the old metric) on both sides > > > > > > > > of the link at > > > > > > the same time, there is no non-determinitic thing in this. > > > > > > > > > > > > > > > > thanks. > > > > > > > > - Naiming > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Following options come to my mind: > > > > > > > > a) when this condition is detected, none of the routers actually > > > > > > > > apply the reverse metric procedure > > > > > > > > b) when this condition is detected, the router with higher/lower > > > > > > > > system-id value (or some such tiebreaker) wins and the other > > > > > > > > withdraws its reverse metric (until then (a) applies) > > > > > > > > c) some mechanism/rule that is based on the value of metric > > > > > > > > offset > > > > > > specified perhaps (made harder since the actual metric is not > > > > > > signalled but > > > > > > the offset) which determines the "winner" so the other withdraws > > > > > > their TLV. > > > > > > > > > > > > > > > > Since the mechanism is not specific to overload conditions > > > > > > > > (where this is > > > > > > not an issue), it may be necessary for the specification to clarify > > > > > > this > > > > > > behaviour to ensure interoperability. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Ketan > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Isis-wg [mailto:[email protected]] On Behalf Of > > > > > > > > Christian Hopps > > > > > > > > Sent: 16 November 2017 04:13 > > > > > > > > To: [email protected]<mailto:[email protected] > > > > > > > > Cc: [email protected]<mailto:[email protected] > > > > > > > > Subject: [Isis-wg] WG Last Call for > > > > > > > > draft-ietf-isis-reverse-metric-07 > > > > > > > > > > > > > > > > > > > > > > > > The authors have asked for and we are starting a WG Last Call on > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ > > > > > > > > > > > > > > > > which will last an extended 3 weeks to allow for IETF100. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Chris. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Isis-wg mailing list > > > > > > > > [email protected]<mailto:[email protected] > > > > > > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Isis-wg mailing list > > > > > > > > [email protected]<mailto:[email protected] > > > > > > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > > > > _______________________________________________ > > > > > > > > Isis-wg mailing list > > > > > > > > [email protected]<mailto:[email protected] > > > > > > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Isis-wg mailing list > > > > > > > > [email protected] > > > > > > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > _______________________________________________ > > > > > Isis-wg mailing list > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > >
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
