Hi Alexander, That’s true. But we do need to handle when in add operation it can also come to the acculative number of (2^24-2) or (2^24-1) and which one to use. So this draft defines normal condition only cap at (2^24-2), unless specified by ‘U’ bit. This way we are consistent in all the cases.
thanks. - Naiming > On Jan 18, 2018, at 10:35 AM, Alexander Okonnikov > <[email protected] <mailto:[email protected]>> wrote: > > 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] > <mailto:[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] <mailto:[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] <mailto:[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] >>>>> <mailto:[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] <mailto:[email protected]> >>>>>>> Cc: Les Ginsberg (ginsberg) <[email protected] >>>>>>> <mailto:[email protected]>>; [email protected] >>>>>>> <mailto:[email protected]>; isis- >>>>>>> [email protected] <mailto:[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] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Naiming Shen (naiming) <[email protected] <mailto:[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]><mailto:[email protected] >>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From: Alexander Okonnikov [mailto:[email protected] >>>>>>>>> <mailto:[email protected]>] >>>>>>>>> Sent: Saturday, December 30, 2017 3:34 PM >>>>>>>>> To: Les Ginsberg (ginsberg) >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> Cc: Naiming Shen (naiming) >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>; Christian Hopps >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[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]><mailto:[email protected] >>>>>>> <mailto:[email protected]>>> написал(а): >>>>>>>>> >>>>>>>>> Alex - >>>>>>>>> >>>>>>>>> From: Alexander Okonnikov [mailto:[email protected] >>>>>>>>> <mailto:[email protected]>] >>>>>>>>> Sent: Saturday, December 30, 2017 3:06 PM >>>>>>>>> To: Les Ginsberg (ginsberg) >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> Cc: Naiming Shen (naiming) >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>; Christian Hopps >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[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]><mailto:[email protected] >>>>>>> <mailto:[email protected]>>> написал(а): >>>>>>>>> >>>>>>>>> Alex - >>>>>>>>> >>>>>>>>> From: Alexander Okonnikov [mailto:[email protected] >>>>>>>>> <mailto:[email protected]>] >>>>>>>>> Sent: Saturday, December 30, 2017 2:38 PM >>>>>>>>> To: Les Ginsberg (ginsberg) >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> Cc: Naiming Shen (naiming) >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>; Christian Hopps >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[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]><mailto:[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] >>>>>>>>> <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]><mailto:[email protected] >>>>>>> <mailto:[email protected]> >>>>>>>>> >>>>>>>>> Cc: [email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>; Christian Hopps >>>>>>>>> <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>; >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[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]><mailto:[email protected] >>>>>>> <mailto:[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Naiming, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 29 дек. 2017 г., в 6:10, Naiming Shen (naiming) >>>>>>> <[email protected] <mailto:[email protected]><mailto:[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]><mailto:[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]><mailto:[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] >>>>>>>>> <mailto:[email protected]>] On Behalf Of >>>>>>>>> Christian Hopps >>>>>>>>> Sent: 16 November 2017 04:13 >>>>>>>>> To: [email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> Cc: [email protected] >>>>>>>>> <mailto:[email protected]><mailto:[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/ >>>>>>>>> <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]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>>>>> <https://www.ietf.org/mailman/listinfo/isis-wg> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Isis-wg mailing list >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>>>>> <https://www.ietf.org/mailman/listinfo/isis-wg> >>>>>>>>> _______________________________________________ >>>>>>>>> Isis-wg mailing list >>>>>>>>> [email protected] <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>>>>> <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 >>>>>>>>> <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 >>>>>> <https://www.ietf.org/mailman/listinfo/isis-wg> >>>> >>> >>
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
