Les,
> 31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg) <[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]>> > 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] > <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. > > > 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] > <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 completed. > > 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 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 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] > <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/ > <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 > <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
