Subject: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Apr 2017 01:01:54 +0000

Naiming/Michael/Shane -

Some comments on the draft.

Section 1.2.  Distributed Forwarding Planes

RFC 5306 (Restart Signaling) has already defined use of the SA bit in the Restart TLV to request that  a neighbor suppress advertisement of the adjacency thus preventing 2-way connectivity check from passing on that link. It is not clear to me why SA bit is not sufficient.

For that matter, the local system could simply not advertise the adjacency to the neighbor and achieve the same result. Why do we need any extension to handle the adjacency bringup case?

Section 1.3 Mobility Cases

I am not clear on why both ISs in such a case would not detect the change in proximity and both do metric adjustment. What is the need for use of reverse metric in this case?

Section 2

>From the description what is being advertised in the new TLV is not a metric but a metric offset i.e. you want the receiving IS to add the advertised value to its existing configured metric. Identifying the metric field as "metric offset" would make this point more clearly.

In regards to the use of sub-TLVs, I think the only use case you have is to advertise a TE metric offset - but this could easily be done as an additional fixed field in the TLV itself. Unless you foresee other sub-TLVs I think sub-TLVs could be eliminated from the TLV definition. (I also think advertising TE metric offset is unnecessary - see additional comments on TE below)

If  you want to retain sub-TLVs for future proofing you do not need both an S flag indicating the presence of sub-TLVs and a sub-TLV length field. One or the other will suffice.

Last Paragraph of Section 3.1 states:

"If the router does not understand the Reverse Metric TLV..."

I don't think this needs to be said. It is standard IS-IS behavior to silently ignore TLVs which are not understood - and if a router does not understand the new TLV it certainly would not know what it is it "should not do". :-)

The point about allowing local policy to disable processing of the Reverse Metric TLV is a good one and the security reasons for it should be emphasized.

Section 3.5

"During the period when a Reverse Metric TLV is used, IS-IS routers

   that are generating and receiving a Reverse Metric TLV MUST NOT

   change their existing IS-IS metric or Traffic Engineering parameters

   in their persistent provisioning database"

I would expect that use of Reverse Metric would often be associated with a maintenance window - in which case this is precisely the time to expect configuration changes. Because traffic has been diverted from the link this is actually the safest time to make configuration changes. Therefore I think this restriction is both unnecessary and undesirable.

Regarding the TE related text

https://www.ietf.org/id/draft-ietf-ospf-link-overload-06.txt  has highlighted that TE CSPF may not always be based on metric (IGP or TE). In which case altering the metric advertisement may not be sufficient to move TE traffic away from the link.

I think a more robust strategy would be to assign a bit in the link attributes sub-TLV defined in RFC 5029 to indicate that the state of the link is "maintenance" (or "overload") and that TE traffic should avoid this. That would be more robust than altering TE metric and would also eliminate the need to use the reverse metric to alter TE metric. Please see https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22 .

   Les

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 26 Apr 2017 07:25:25 +0200 (CEST)

Hi,

Thanks for the review!

Regarding 3.5. I think the point here is that when the device received a 
reverse metric offset request, it should not reflect this in the 
persistent configuration storage. The operational metric change is 
ephemeral (I think this is the correct term), not a persistent storage 
change. So the idea here is that there should be no “automatic” update of 
the “running-config” metric setting, just because one is sending or 
receiving a metric-offset TLV. This should be a separate configuration 
item.

Regarding not advertising adjacency at all. Personally, I like to be able 
to take links into a state of “don’t use this unless you absolutely have 
to”. Stopping advertising it at all, takes away that possibility. If I 
have two redundant links to somewhere, one has bit errors, this is 
automatically detected and that link is now “metric:ed up” so it’s not 
used. If the second link goes down, I’d rather send traffic over this 
bit-errored link, than to lose connectivity at all. So if this was a g.709 
forward-error-correction (FEC) covered link, I can configure the router to 
metric-up the link at a certain FEC corrected-errors rate, so that I don’t 
get post-FEC errors. This doesn’t mean the link is unusable as an 
emergency backup if it’s the only one left, it just means I want to avoid 
using it.

Does the draft need text to better explain this?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Apr 2017 13:13:32 +0000

Mikael -

Thanx for the quick response - look forward to your replies on the other points.
Inline.

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2017 10:25 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05
> 
> 
> Hi,
> 
> Thanks for the review!
> 
> reverse metric offset request, it should not reflect this in the persistent
> configuration storage. The operational metric change is ephemeral (I think
> this is the correct term), not a persistent storage change. So the idea here is
> that there should be no “automatic” update of the “running-config” metric
> setting, just because one is sending or receiving a metric-offset TLV. This
> should be a separate configuration item.
> 
[Les:] We are in agreement as to the intent - I think the draft wording can be improved. Currently it says:

" During the period when a Reverse Metric TLV is used, IS-IS routers
   that are generating and receiving a Reverse Metric TLV MUST NOT
   change their existing IS-IS metric or Traffic Engineering parameters
   in their persistent provisioning database..."

How about 

"The use of Reverse Metric does not alter IS-IS metric parameters stored in a router's persistent provisioning database."

??

> Regarding not advertising adjacency at all. Personally, I like to be able to take
> links into a state of “don’t use this unless you absolutely have to”. Stopping
> advertising it at all, takes away that possibility. If I have two redundant links
> to somewhere, one has bit errors, this is automatically detected and that link
> is now “metric:ed up” so it’s not used. If the second link goes down, I’d
> rather send traffic over this bit-errored link, than to lose connectivity at all. So
> if this was a g.709 forward-error-correction (FEC) covered link, I can configure
> the router to metric-up the link at a certain FEC corrected-errors rate, so that
> I don’t get post-FEC errors. This doesn’t mean the link is unusable as an
> emergency backup if it’s the only one left, it just means I want to avoid using
> it.
> 
[Les:] Here you are commenting on Section 1.2 - which is a startup problem - in this case start/restart of a line card.
Line card bringup is quite different from other cases addressed by the draft.

The use case for reverse metric is to make a link (or set of links)  the link of last resort i.e. the desire is for the link to still be usable but to minimize its use. This would allow - for example - testing of the link without having it used for live traffic. The lack of current information in the forwarding plane is not an issue and the IS-IS adjacencies are already up.

In the case of LC restart, IS-IS adjacencies have to be formed and forwarding plane state is initially empty and has to be (re)populated. In this case there is no requirement to use the link for testing purposes during the transition. - which should be a matter of seconds.  This is operationally no different from what occurs when a link fails and is then restored. I do not see the need for any special handling of this case - and I do not see that the reverse-metric functionality is useful in this case.

   Les

> > RFC 5306 (Restart Signaling) has already defined use of the SA bit in the
> Restart TLV to request that  a neighbor suppress advertisement of the
> adjacency thus preventing 2-way connectivity check from passing on that
> link. It is not clear to me why SA bit is not sufficient.
> >
> > For that matter, the local system could simply not advertise the adjacency
> to the neighbor and achieve the same result. Why do we need any extension
> to handle the adjacency bringup case?
> >
> >
> >
> > I am not clear on why both ISs in such a case would not detect the change
> in proximity and both do metric adjustment. What is the need for use of
> reverse metric in this case?
> >
> >
> >
> >
> >
> > Section 2
> >
> >
> >
> >> From the description what is being advertised in the new TLV is not a
> metric but a metric offset i.e. you want the receiving IS to add the advertised
> value to its existing configured metric. Identifying the metric field as "metric
> offset" would make this point more clearly.
> >
> >
> >
> > In regards to the use of sub-TLVs, I think the only use case you have
> > is to advertise a TE metric offset - but this could easily be done as
> > an additional fixed field in the TLV itself. Unless you foresee other
> > sub-TLVs I think sub-TLVs could be eliminated from the TLV definition.
> > (I also think advertising TE metric offset is unnecessary - see
> > additional comments on TE below)
> >
> >
> >
> > If  you want to retain sub-TLVs for future proofing you do not need both an
> S flag indicating the presence of sub-TLVs and a sub-TLV length field. One or
> the other will suffice.
> >
> >
> >
> >
> >
> > I don't think this needs to be said. It is standard IS-IS behavior to
> > silently ignore TLVs which are not understood - and if a router does
> > not understand the new TLV it certainly would not know what it is it
> > "should not do". :-)
> >
> >
> >
> > The point about allowing local policy to disable processing of the Reverse
> Metric TLV is a good one and the security reasons for it should be
> emphasized.
> >
> >
> >
> >
> >
> > Section 3.5
> >
> >
> >
> > I would expect that use of Reverse Metric would often be associated with a
> maintenance window - in which case this is precisely the time to expect
> configuration changes. Because traffic has been diverted from the link this is
> actually the safest time to make configuration changes. Therefore I think this
> restriction is both unnecessary and undesirable.
> >
> >
> >
> > https://www.ietf.org/id/draft-ietf-ospf-link-overload-06.txt  has
> highlighted that TE CSPF may not always be based on metric (IGP or TE). In
> which case altering the metric advertisement may not be sufficient to move
> TE traffic away from the link.
> >
> >
> >
> > I think a more robust strategy would be to assign a bit in the link attributes
> sub-TLV defined in RFC 5029 to indicate that the state of the link is
> "maintenance" (or "overload") and that TE traffic should avoid this. That
> would be more robust than altering TE metric and would also eliminate the
> need to use the reverse metric to alter TE metric. Please see
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-
> codepoints.xhtml#isis-tlv-codepoints-19of22 .
> >
> >
> >
> >   Les
> >
> >
> >
> >
> >
> 
> --

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 27 Apr 2017 01:46:58 +0000

Les,

Thanks for the detailed comments. See some of my replies inline
between [NS->] [<-NS]:

On Apr 25, 2017, at 6:01 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Naiming/Michael/Shane -

[NS->]
I have some points on this:
(1) if the linecard resets on the router, that is not a graceful restart case for IS-IS
(2) related to the comments you were with Mikael on the ‘a matter of seconds’,
      this issue is more with BGP VPN than with IS-IS routes. IS-IS routes can be
      downloaded into the line card quickly, but millions of VPN routes may take
      a while
(3) During this ‘take a while’, we still want to be the last resort of connection
      to our neighbors, instead of just blindly refuse any traffic inbound
(4) Outbound traffic direction may not have any problem, we certainly want
      to reuse the link as soon as possible.

How about we add some text to refer to those reasonings on this use-case?
[<-NS]

[NS->]
Yes, you are right if the link is point-to-point. As described in RFC 8042
“OSPF Two-Part Metric”, if the base-station is the DIS, it does not want
to set link metric for all the remote stations, and it could be only one
remote station moves away or closer.

How about we remove the point-to-point circuit in the text of this use-case?
[<-NS]

Section 2

[NS->]
Agreed.
[<-NS]

In regards to the use of sub-TLVs, I think the only use case you have is to advertise a TE metric offset - but this could easily be done as an additional fixed field in the TLV itself. Unless you foresee other sub-TLVs I think sub-TLVs could be eliminated from the TLV definition. (I also think advertising TE metric offset is unnecessary – see additional comments on TE below)

[NS->]
I think we were mainly for future proofing point on this. Sure, will get rid of the S flag.
[<-NS]

[NS->]
Agreed. Wll remove this sentence.
[<-NS]

Section 3.5

[NS->]
Your suggested text (thread with Mikael):
"The use of Reverse Metric does not alter IS-IS metric parameters stored in a router's persistent provisioning database.”
looks good to me.
[<-NS]

[NS->]
Sure, TE can be impacted by ‘color’, link congestion data from inband or out-band,
and many other things. Its hard to cover all the things from SND point of view.
[<-NS]

[NS->]
Ok. But which TE traffic? You can say even if it’s ‘overloaded’ I still want to
send certain TE traffic over. When this side of the link pushes a large
offset value of reverse-metric over and the other side adds this to the
link metric and TE metric values, if the controller wants to detect this
condition (normally the network uses metric below 3000, and this
link suddenly has the value of a billion, I’ll conside the other side of
this link is ‘overloaded’.

I’m just saying I’m not sure if this is a real case. We can certainly
add that if needed.
[<-NS]

Best Regards,
- Naiming

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Apr 2017 04:07:47 +0000

Naiming –

Thanx for the reply.
Inline – look for LES:

From: Naiming Shen (naiming)
Sent: Wednesday, April 26, 2017 6:47 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-isis-reverse-metric-05

Les,

Naiming/Michael/Shane -

[NS->]

[Les:] SA bit is not restricted to restart cases. This is discussed in RFC 5306. But SA bit is probably not the right mechanism here either as it is designed to delay adjacency advertisement until the full link state DB is acquired – this isn’t relevant here. Apologies for mentioning it.

But in cases where the trigger (link/adjacency up) is known to all impacted routers at the same time reverse-metric is unnecessary.

Reverse metric can be useful when you want to administratively change the state of an operational link and have it impact traffic flow in both directions. Because  there is no change to the operational state of the link all affected routers have to be notified of the administrative state change in some manner – reverse-metric makes this more convenient by requiring the administrative command to be signaled only on one node and have it immediately propagated to the other affected nodes. But it serves no purpose in cases where the operational state of the link is already being signaled to the control plane of all affected routers. it is in fact redundant in such cases as each router is already aware. If you use reverse-metric in such a case both routers will each tell the other one to do something that they are already doing.

[NS->]

[Les:] I am struggling to see reverse-metric as equivalent to RFC 8042. If we support RFC 8042 then we don’t need reverse-metric.
If we do not support RFC 8042, reverse-metric does not provide the same optimization as RFC 8042 as it requires multiple routers to send updates. Are you really positioning reverse-metric as an RFC 8042 alternative?
Or am I missing something?

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

[Les:] We agree that we do not want to try to account for every possible set of constraints. Metric is one possible constraint – but I do not see that it makes sense to treat this in a special way. If instead of modifying TE metric we advertise a link state (“maintenance” or “overload”) then TE on each router can decide for itself what adjustments it should make to all of the local tunnels independent of the set of constraints each tunnel has.

   Les

Best Regards,
- Naiming

   Les

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 27 Apr 2017 11:32:56 +0300

Hi authors,

In the beginning of the section 3.3 you say that non-DIS routers should 
not take into account reverse metric. But wouldn't it break reverse 
metric application? Router that running SPF puts into TENT all routers 
from its adjacency database (not only DIS, as OSPF does). Hence, to the 
router that have originated Reverse Metric TLV, some non-DIS router will 
have two alternative paths - direct (with regular metric) and via DIS 
(with composite metric). As a result, it will choose direct path. 
Please, correct me if I am wrong.

Thank you.

27.04.2017 07:07, Les Ginsberg (ginsberg) пишет:
>
> Naiming –
>
> Thanx for the reply.
>
> Inline – look for LES:
>
> *From:*Naiming Shen (naiming)
> *Sent:* Wednesday, April 26, 2017 6:47 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: Comments on draft-ietf-isis-reverse-metric-05
>
> Les,
>
>     On Apr 25, 2017, at 6:01 PM, Les Ginsberg (ginsberg)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Naiming/Michael/Shane -
>
>     *Section 1.2.  Distributed Forwarding Planes*
>
>     RFC 5306 (Restart Signaling) has already defined use of the SA bit
>     in the Restart TLV to request that  a neighbor suppress
>     advertisement of the adjacency thus preventing 2-way connectivity
>     check from passing on that link. It is not clear to me why SA bit
>     is not sufficient.
>
>     For that matter, the local system could simply not advertise the
>     adjacency to the neighbor and achieve the same result. Why do we
>     need any extension to handle the adjacency bringup case?
>
> [NS->]
>
> */[Les:] SA bit is not restricted to restart cases. This is discussed 
> in RFC 5306. But SA bit is probably not the right mechanism here 
> either as it is designed to delay adjacency advertisement until the 
> full link state DB is acquired – this isn’t relevant here. Apologies 
> for mentioning it./*
>
> *//*
>
> */But in cases where the trigger (link/adjacency up) is known to all 
> impacted routers at the same time reverse-metric is unnecessary./*
>
> *//*
>
> */Reverse metric can be useful when you want to administratively 
> change the state of an operational link and have it impact traffic 
> flow in both directions. Because  there is no change to the 
> operational state of the link all affected routers have to be notified 
> of the administrative state change in some manner – reverse-metric 
> makes this more convenient by requiring the administrative command to 
> be signaled only on one node and have it immediately propagated to the 
> other affected nodes. But it serves no purpose in cases where the 
> operational state of the link is already being signaled to the control 
> plane of all affected routers. it is in fact redundant in such cases 
> as each router is already aware. If you use reverse-metric in such a 
> case both routers will each tell the other one to do something that 
> they are already doing./*
>
> *Section 1.3 Mobility Cases*
>
> I am not clear on why both ISs in such a case would not detect the 
> change in proximity and both do metric adjustment. What is the need 
> for use of reverse metric in this case?
>
> [NS->]
>
> */[Les:] I am struggling to see reverse-metric as equivalent to RFC 
> 8042. If we support RFC 8042 then we don’t need reverse-metric./*
>
> */If we do not support RFC 8042, reverse-metric does not provide the 
> same optimization as RFC 8042 as it requires multiple routers to send 
> updates. Are you really positioning reverse-metric as an RFC 8042 
> alternative?/*
>
> */Or am I missing something?/*
>
> *//*
>
> *Section 2*
>
> metric but a metric offset i.e. you want the receiving IS to add the 
> advertised value to its existing configured metric. Identifying the 
> metric field as "metric offset" would make this point more clearly.
>
> [NS->]
>
> Agreed.
>
> [<-NS]
>
> (I also think advertising TE metric offset is unnecessary – see 
> If  you want to retain sub-TLVs for future proofing you do not need 
> both an S flag indicating the presence of sub-TLVs and a sub-TLV 
> length field. One or the other will suffice.
>
> [NS->]
>
>     *Last Paragraph of Section 3.1 states:*
>
>     I don't think this needs to be said. It is standard IS-IS behavior
>     to silently ignore TLVs which are not understood - and if a router
>     does not understand the new TLV it certainly would not know what
>     it is it "should not do". :-)
>
>     The point about allowing local policy to disable processing of the
>     Reverse Metric TLV is a good one and the security reasons for it
>     should be emphasized.
>
> [NS->]
>
>     *Section 3.5*
>     I would expect that use of Reverse Metric would often be
>     associated with a maintenance window - in which case this is
>     precisely the time to expect configuration changes. Because
>     traffic has been diverted from the link this is actually the
>     safest time to make configuration changes. Therefore I think this
> "The use of Reverse Metric does not alter IS-IS metric parameters 
> stored in a router's persistent provisioning database.”
>
> looks good to me.
>
> [<-NS]
>
>     *Regarding the TE related text*
>
>     highlighted that TE CSPF may not always be based on metric (IGP or
>     TE). In which case altering the metric advertisement may not be
>     sufficient to move TE traffic away from the link.
>
> [NS->]
>
>     I think a more robust strategy would be to assign a bit in the
>     link attributes sub-TLV defined in RFC 5029 to indicate that the
>     state of the link is "maintenance" (or "overload") and that TE
>     traffic should avoid this. That would be more robust than altering
>     TE metric and would also eliminate the need to use the reverse
>     metric to alter TE metric. Please
>     seehttps://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22.
>
> [NS->]
>
> */[Les:] We agree that we do not want to try to account for every 
> possible set of constraints. Metric is one possible constraint – but I 
> do not see that it makes sense to treat this in a special way. If 
> instead of modifying TE metric we advertise a link state 
> (“maintenance” or “overload”) then TE on each router can decide for 
> itself what adjustments it should make to all of the local tunnels 
> independent of the set of constraints each tunnel has. /*
>
> *//*
>
> Les
>
> Best Regards,
>
> - Naiming
>
>
>
> Les
>
>
>
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 27 Apr 2017 19:13:24 +0000

Hi Alexander,

What this paragraph meant is that, since the ‘reverse-metric’ TLV is inside
the IIH PDU, which has nothing to do with the SPF, and only the DIS will
respond to this IIH PDU that contains ‘reverse-metric’ TLV (to add the
offset-metric in the pseudo-node LSP). As long as the DIS changes it’s
pseudo-node LSP, all the nodes in the domain will see and run SPF
the same way. The non-DIS node sees this TLV of IIH PDU, it has no
way of processing that since they don’t generate pnode-LSPs.

We can make the text clearer on this.

thanks.
- Naiming

On Apr 27, 2017, at 1:32 AM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi authors,

In the beginning of the section 3.3 you say that non-DIS routers should not take into account reverse metric. But wouldn't it break reverse metric application? Router that running SPF puts into TENT all routers from its adjacency database (not only DIS, as OSPF does). Hence, to the router that have originated Reverse Metric TLV, some non-DIS router will have two alternative paths - direct (with regular metric) and via DIS (with composite metric). As a result, it will choose direct path. Please, correct me if I am wrong.

Thank you.

Thanx for the reply.
Inline – look for LES:

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 27 Apr 2017 23:24:28 +0300

Hi Naiming,

I'm talking about SPF that is running on non-DIS router connected to the LAN. Let's assume that we have LAN with three routers - R1, R2, and R3. R1 is a regular non-DIS, R2 - non-DIS that advertises Reverse metric, and R3 - DIS. Now let's look at R1's SPF process (from RFC 1195 which extends SPF from ISO 10589 for handling of IP reachability). It is supposed that R1 has established adjacencies with R2 and R3. R1 (at step 0) adds R2 and R3 (R1's adjacency database) into its TENT list (each with metric equal to R1's interface metric). Then R1 analyses pseudonode LSP for adjacencies that pseudonode LSP has, but R1 doesn't. As soon as there are no such adjacencies (LAN is not split), R1 goes to step 2 (moves adjacencies from TENT to PATHS) and eventually to step 1. At this step it calculates routes to prefixes connected to R2 and R3 and then iterates SPF to step 0 (analyses R2's and R3's LSPs). As mentioned above, R2 advertises Reverse metric (in its Hello message), but it is ignored by R1. Hence R1 has routes to prefixes behind R2 with metric of link R1-R2 equal to R1's interface metric, rather than R1's interface metric + R2's Reverse metric offset.

Of course, routers that are behind the LAN, will correctly derive modified metric from pseudonode LSP of that LAN.

Thank you.

On 27 апр. 2017 г., 22:13 +0300, Naiming Shen (naiming) <[email-masked]>, wrote:
> > On Apr 27, 2017, at 1:32 AM, Alexander Okonnikov <[email-masked]> wrote:
> >
> > Hi authors,
> >
> > > > On Apr 25, 2017, at 6:01 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> > > >
> > > > Naiming/Michael/Shane -
> > > >

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 27 Apr 2017 22:11:18 +0000

Hi Alexander,

Ok, got you. Although the spec also says it needs to do ‘Two-way connectivity check’ in order
to use this IS-IS system in your SPF. Even the R1 has the adjacency to the R2, but the
R2’s LSP does not show the ‘IS Neighbor’ to R1, it only has the ‘IS Neighbor’ on this LAN to
R3’s Pnode. The ’Two-way connectivity check’ fails. So in the SPF for R1 to connect to R2,
it needs to go R1< -> R3 Pnode <-> R2.

The reverse-metric from R3’s Pnode towards R2 now will be used by both R3 and R1, and
any remote nodes not on the LAN.

thanks.
- Naiming

On Apr 27, 2017, at 1:24 PM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Naiming,

Thank you.

On 27 апр. 2017 г., 22:13 +0300, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Alexander,

thanks.
- Naiming

Hi authors,

Thank you.

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 28 Apr 2017 01:12:46 +0300

Hi Naiming,

Two-way connectivity check is performed by virtue of LAN Hello. When both routers see each other in their LAN Hellos (3-way handshake on LAN) they conclude that adjacency has been established. No needs to analyse LSP of each other.

Thank you.

On 28 апр. 2017 г., 1:11 +0300, Naiming Shen (naiming) <[email-masked]>, wrote:
> > On Apr 27, 2017, at 1:24 PM, Alexander Okonnikov <[email-masked]> wrote:
> >
> > Hi Naiming,
> >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Apr 2017 22:26:45 +0000

Alex –

This is NOT correct – if it were SPF would be broken because nodes remote from the LAN – who do not see the hellos – would see the topology differently than the nodes connected to the LAN.

See ISO 10589:2002 Section 7.2.8.2 Two-way connectivity check

“The Decision Process shall not utilise a link between two Intermediate Systems unless both ISs report the link.”

   Les

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Thursday, April 27, 2017 3:13 PM
To: Naiming Shen (naiming)
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Hi Naiming,

Thank you.

On 28 апр. 2017 г., 1:11 +0300, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Alexander,

thanks.
- Naiming

Hi Naiming,

Thank you.

Hi Alexander,

thanks.
- Naiming

Hi authors,

Thank you.

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

Isis-wg mailing list

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 27 Apr 2017 22:30:36 +0000

Les,

We’ll add more text into the section 1.2 ‘Distributed Forwarding Planes.
We’ll remove the reference to mobility in the text.

thanks.
- Naiming

On Apr 26, 2017, at 9:07 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 27 Apr 2017 22:33:10 +0000

and add a bit to ‘link-attribute’ bit value of the sub-TLV 19
in the codepoint registry.

thanks.
- Naiming

On Apr 27, 2017, at 3:30 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Apr 2017 22:38:01 +0000

Thanx Naiming – sounds good.

   Les

Sent: Thursday, April 27, 2017 3:33 PM

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 28 Apr 2017 02:34:01 +0300

Hi Les,

Yes, I agree that two-way check via LSPs is performed, thank you for correction.

The problem that I'm talking is that in step 0 neighbors are put on the TENT from adjacency database, not from LSP of the router that is running SPF. Hence, for example above, when R1 will install routes via R2, metric for those routes will be based on the metric of R1's LAN interface, and not on sum of metrics 'R1 -> pseudonode' + 'pseudonode -> R2' from LSPs.

28 апр. 2017 г., 1:41 +0300, Les Ginsberg (ginsberg) <[email-masked]>, писал:
> > On Apr 27, 2017, at 3:30 PM, Naiming Shen (naiming) <[email-masked] (mailto:[email-masked])> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Les,
> >
> >
> >
> >
> >
> >
> > > On Apr 26, 2017, at 9:07 PM, Les Ginsberg (ginsberg) <[email-masked] (mailto:[email-masked])> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Naiming –
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Thanx for the reply.
> > >
> > >
> > >
> > > Inline – look for LES:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Cc: [email-masked] (mailto:[email-masked]); [email-masked] (mailto:[email-masked])
> > > > On Apr 25, 2017, at 6:01 PM, Les Ginsberg (ginsberg) <[email-masked] (mailto:[email-masked])> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Naiming/Michael/Shane -
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Apr 2017 23:51:16 +0000

Alex –

I think you are referring to ISO 10589:2002 Annex C.2.4
Note that this section is non-normative and is simply describing one possible way to implement the algorithm. When  there is a question between this description and the normative portions of the specification the normative portions MUST be followed.

Note that some implementations choose to initialize the tent from their own LSPs..

   Les

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Thursday, April 27, 2017 4:34 PM
To: Naiming Shen (naiming); Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Hi Les,

28 апр. 2017 г., 1:41 +0300, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>, писал:

   Les

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 28 Apr 2017 02:55:56 +0300

Les,

Exactly, and my concern about other implementations that adhere that Annex.

May be it would be good to make clarification in the draft about these specifics.

Thank you!

28 апр. 2017 г., 2:51 +0300, Les Ginsberg (ginsberg) <[email-masked]>, писал:
> 28 апр. 2017 г., 1:41 +0300, Les Ginsberg (ginsberg) <[email-masked] (mailto:[email-masked])>, писал:
>
>
>
>
> [email-masked] (mailto:[email-masked])

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 27 Apr 2017 23:59:22 +0000

Hi Alex,

Will add this ‘Two-way connectivity check’ requirement to emphysize the point
in that section.

thanks.
- Naiming

On Apr 27, 2017, at 4:55 PM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> wrote:

Les,

Thank you!

28 апр. 2017 г., 2:51 +0300, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>, писал:
Alex –

   Les

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Les,

   Les

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 28 Apr 2017 03:24:24 +0300

Naiming,

One more comment about Appendix C of the draft. Description looks like this use case is applicable only for LDP session between DIS and non-DIS with Reverse metric. What about LDP sessions between pairs of any routers on the LAN? I.e. may be it would be better to replace 'LDP adjacency to the DIS' by 'LDP adjacencies to other routers on the LAN', and 'completion of transmission of End-of-LIB towards DIS' by 'completion of transmission of End-of-LIB on all LDP sessions with routers on the LAN'.

Thank you.

28 апр. 2017 г., 2:59 +0300, Naiming Shen (naiming) <[email-masked]>, писал:
> > On Apr 27, 2017, at 4:55 PM, Alexander Okonnikov <[email-masked] (mailto:[email-masked])> wrote:
> > Les,
> >
> > 28 апр. 2017 г., 2:51 +0300, Les Ginsberg (ginsberg) <[email-masked] (mailto:[email-masked])>, писал:
> > >
> > > Alex –
> > >
> > >
> > >
> > > Cc: [email-masked] (mailto:[email-masked]); [email-masked] (mailto:[email-masked])

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 28 Apr 2017 00:33:14 +0000

Hi Alex,

Sure. Will do. thanks.

- Naiming

On Apr 27, 2017, at 5:24 PM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> wrote:

Naiming,

Thank you.

28 апр. 2017 г., 2:59 +0300, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>, писал:

Hi Alex,

thanks.
- Naiming

Les,

Thank you!

   Les

Hi Les,

   Les

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 30 Apr 2017 14:37:01 +0000

Naiming/Alex –

Regarding Appendix C, I think you have to be careful here.

If a LAN is operational with three nodes (A, B, C) – all LDP sessions established, then a new node (D) is introduced to the LAN, what should one do?

As RFC 5443 states (Section 3):

“On broadcast links with more than one IGP/LDP peer, the cost-out
   procedure can only be applied to the link as a whole and not to an
   individual peer.  So a policy decision has to be made whether the
   unavailability of LDP service to one peer should result in the
   traffic being diverted away from all the peers on the link.”

If you are going to position reverse-metric as an alternative/enhancement to RFC 5443 I think you need to discuss this is more detail.

For myself, I can see that reverse-metric would be useful in a node startup case where the new node would steer traffic away from the LAN when the nexthop was itself – but I would be reluctant to use it after startup when some other node comes up.

I also think a non-normative reference to RFC 5443 would be in order.

   Les

From: Naiming Shen (naiming)
Sent: Thursday, April 27, 2017 5:33 PM
To: Alexander Okonnikov
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Hi Alex,

Sure. Will do. thanks.

- Naiming

Naiming,

Thank you.

Hi Alex,

thanks.
- Naiming

Les,

Thank you!

Alex –

   Les

Hi Les,

   Les

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: Alexander Okonnikov <[email-masked]>
Date: Sun, 30 Apr 2017 19:10:04 +0300

Hi Les,

I think that this is alternative to RFC 6138 and complement to RFC 5443. 
Per my understanding, it is supposed that only startup router is 
responsible for advertising Reverse metric. It also applies procedure 
from RFC 5443 (i.e. increases its forward metric). According to that, 
all other routers on the LAN will have high metric towards startup 
router. Startup router also has high metric towards LAN (per RFC 5443). 
At the same time routers on the LAN, except startup router, can use this 
LAN for transit traffic. I expect that other routers will not apply RFC 
5443 on this LAN and will not advertise Reverse metric when new node 
appears on the LAN, unless for startup of their own interface to this 
LAN. To make this procedure reliable, other router can monitor metric 
over LAN towards startup router, and if it equals to 2^24-2 (assumed 
that Reverse metric value will be 2^24-2 for this application), they 
don't apply procedure from RFC 5443. Otherwise they fallback to RFC 5443 
(DIS is not compatible to the draft and ignores Reverse metric). Once 
startup router has received EoL over all LDP sessions over LAN (or their 
synchronization timeouts have been expired), it could revert its forward 
metric back to configured one. Once it have sent EoL over all LDP 
sessions over LAN, it ceases advertisement of its Reverse metric.

Nevertheless, let's wait Naiming's clarifications on this.

Thank you.

30.04.2017 17:37, Les Ginsberg (ginsberg) пишет:
> If a LAN is operational with three nodes (A, B, C) – all LDP sessions 
> established, then a new node (D) is introduced to the LAN, what should 
> one do?
>
> If you are going to position reverse-metric as an 
> alternative/enhancement to RFC 5443 I think you need to discuss this 
> is more detail.
>
> For myself, I can see that reverse-metric would be useful in a node 
> startup case where the new node would steer traffic away from the LAN 
> when the nexthop was itself – but I would be reluctant to use it after 
> startup when some other node comes up.
>
> *Sent:* Thursday, April 27, 2017 5:33 PM
> *To:* Alexander Okonnikov
> *Cc:* Les Ginsberg (ginsberg); 
> [email-masked]; [email-masked]
> *Subject:* Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05
>
> Hi Alex,
>
> Sure. Will do. thanks.
>
> - Naiming
>
>     On Apr 27, 2017, at 5:24 PM, Alexander Okonnikov
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     Naiming,
>
>     One more comment about Appendix C of the draft. Description looks
>     like this use case is applicable only for LDP session between DIS
>     and non-DIS with Reverse metric. What about LDP sessions between
>     pairs of any routers on the LAN? I.e. may be it would be better to
>     replace 'LDP adjacency to the DIS' by 'LDP adjacencies to other
>     routers on the LAN', and 'completion of transmission of End-of-LIB
>     towards DIS' by 'completion of transmission of End-of-LIB on all
>     LDP sessions with routers on the LAN'.
>
>     Thank you.
>
>
>     28 апр. 2017 г., 2:59 +0300, Naiming Shen (naiming)
>     <[email-masked] <mailto:[email-masked]>>, писал:
>
>     Hi Alex,
>
>         On Apr 27, 2017, at 4:55 PM, Alexander Okonnikov
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         Les,
>
>         28 апр. 2017 г., 2:51 +0300, Les Ginsberg (ginsberg)
>         <[email-masked] <mailto:[email-masked]>>, писал:
>
>         Alex –
>
>         Note that this section is non-normative and is simply
>         describing one possible way to implement the algorithm. When
>         there is a question between this description and the normative
>         portions of the specification the normative portions MUST be
>         followed.
>
>         *From:* Alexander Okonnikov [mailto:[email-masked]]
>         *Sent:* Thursday, April 27, 2017 4:34 PM
>         *To:* Naiming Shen (naiming); Les Ginsberg (ginsberg)
>         *Cc:* [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>
>         *Subject:* Re: [Isis-wg] Comments on
>         draft-ietf-isis-reverse-metric-05
>
>         Hi Les,
>
>         The problem that I'm talking is that in step 0 neighbors are
>         put on the TENT from adjacency database, not from LSP of the
>         router that is running SPF. Hence, for example above, when R1
>         will install routes via R2, metric for those routes will be
>         based on the metric of R1's LAN interface, and not on sum of
>         metrics 'R1 -> pseudonode' + 'pseudonode -> R2' from LSPs.
>
>
>         28 апр. 2017 г., 1:41 +0300, Les Ginsberg (ginsberg)
>         <[email-masked] <mailto:[email-masked]>>, писал:
>
>         *From:* Naiming Shen (naiming)
>         *Sent:* Thursday, April 27, 2017 3:33 PM
>         *Cc:* [email-masked] <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>
>             On Apr 27, 2017, at 3:30 PM, Naiming Shen (naiming)
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Les,
>
>                 On Apr 26, 2017, at 9:07 PM, Les Ginsberg (ginsberg)
>                 *Sent:*Wednesday, April 26, 2017 6:47 PM
>                 *To:*Les Ginsberg (ginsberg)
>                 *Cc:[email-masked]
>                 <mailto:[email-masked]>;[email-masked]
>                 <mailto:[email-masked]>
>                 *Subject:*Re: Comments on
>                 draft-ietf-isis-reverse-metric-05
>
>                 Les,
>
>                     On Apr 25, 2017, at 6:01 PM, Les Ginsberg
>                     (ginsberg) <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                     Naiming/Michael/Shane -
>
>                     RFC 5306 (Restart Signaling) has already defined
>                     use of the SA bit in the Restart TLV to request
>                     that  a neighbor suppress advertisement of the
>                     adjacency thus preventing 2-way connectivity check
>                     from passing on that link. It is not clear to me
>                     why SA bit is not sufficient.
>
>                     For that matter, the local system could simply not
>                     advertise the adjacency to the neighbor and
>                     achieve the same result. Why do we need any
>                     extension to handle the adjacency bringup case?
>
>                 [NS->]
>
>                 */[Les:] SA bit is not restricted to restart cases.
>                 This is discussed in RFC 5306. But SA bit is probably
>                 not the right mechanism here either as it is designed
>                 to delay adjacency advertisement until the full link
>                 state DB is acquired – this isn’t relevant here.
>                 Apologies for mentioning it./*
>
>                 *//*
>
>                 */But in cases where the trigger (link/adjacency up)
>                 is known to all impacted routers at the same time
>                 reverse-metric is unnecessary./*
>
>                 *//*
>
>                 */Reverse metric can be useful when you want to
>                 administratively change the state of an operational
>                 link and have it impact traffic flow in both
>                 directions. Because  there is no change to the
>                 operational state of the link all affected routers
>                 have to be notified of the administrative state change
>                 in some manner – reverse-metric makes this more
>                 convenient by requiring the administrative command to
>                 be signaled only on one node and have it immediately
>                 propagated to the other affected nodes. But it serves
>                 no purpose in cases where the operational state of the
>                 link is already being signaled to the control plane of
>                 all affected routers. it is in fact redundant in such
>                 cases as each router is already aware. If you use
>                 reverse-metric in such a case both routers will each
>                 tell the other one to do something that they are
>                 already doing./*
>
>                 I am not clear on why both ISs in such a case would
>                 not detect the change in proximity and both do metric
>                 adjustment. What is the need for use of reverse metric
>                 in this case?
>
>                 [NS->]
>
>                 */[Les:] I am struggling to see reverse-metric as
>                 equivalent to RFC 8042. If we support RFC 8042 then we
>                 don’t need reverse-metric./*
>
>                 */If we do not support RFC 8042, reverse-metric does
>                 not provide the same optimization as RFC 8042 as it
>                 requires multiple routers to send updates. Are you
>                 really positioning reverse-metric as an RFC 8042
>                 alternative?/*
>
>                 From the description what is being advertised in the
>                 new TLV is not a metric but a metric offset i.e. you
>                 want the receiving IS to add the advertised value to
>                 its existing configured metric. Identifying the metric
>                 field as "metric offset" would make this point more
>                 clearly.
>
>                 [NS->]
>
>                 Agreed.
>
>                 [<-NS]
>
>                 In regards to the use of sub-TLVs, I think the only
>                 use case you have is to advertise a TE metric offset -
>                 but this could easily be done as an additional fixed
>                 field in the TLV itself. Unless you foresee other
>                 sub-TLVs I think sub-TLVs could be eliminated from the
>                 TLV definition. (I also think advertising TE metric
>                 offset is unnecessary – see additional comments on TE
>                 below)
>
>                 If  you want to retain sub-TLVs for future proofing
>                 you do not need both an S flag indicating the presence
>                 of sub-TLVs and a sub-TLV length field. One or the
>                 other will suffice.
>
>                 [NS->]
>
>                     I don't think this needs to be said. It is
>                     standard IS-IS behavior to silently ignore TLVs
>                     which are not understood - and if a router does
>                     not understand the new TLV it certainly would not
>                     know what it is it "should not do". :-)
>
>                     The point about allowing local policy to disable
>                     processing of the Reverse Metric TLV is a good one
>                     and the security reasons for it should be emphasized.
>
>                 [NS->]
>
>                     I would expect that use of Reverse Metric would
>                     often be associated with a maintenance window - in
>                     which case this is precisely the time to expect
>                     configuration changes. Because traffic has been
>                     diverted from the link this is actually the safest
>                     time to make configuration changes. Therefore I
>                     think this restriction is both unnecessary and
>                     undesirable.
>
>                 [NS->]
>
>                 "The use of Reverse Metric does not alter IS-IS metric
>                 parameters stored in a router's persistent
>                 provisioning database.”
>
>                 looks good to me.
>
>                 [<-NS]
>
>                     highlighted that TE CSPF may not always be based
>                     on metric (IGP or TE). In which case altering the
>                     metric advertisement may not be sufficient to move
>                     I think a more robust strategy would be to assign
>                     a bit in the link attributes sub-TLV defined in
>                     RFC 5029 to indicate that the state of the link is
>                     "maintenance" (or "overload") and that TE traffic
>                     should avoid this. That would be more robust than
>                     altering TE metric and would also eliminate the
>                     need to use the reverse metric to alter TE metric.
>                     Please
>                 */[Les:] We agree that we do not want to try to
>                 account for every possible set of constraints. Metric
>                 is one possible constraint – but I do not see that it
>                 makes sense to treat this in a special way. If instead
>                 of modifying TE metric we advertise a link state
>                 (“maintenance” or “overload”) then TE on each router
>                 can decide for itself what adjustments it should make
>                 to all of the local tunnels independent of the set of
>                 constraints each tunnel has./*
>
>                 *//*
>
>                 Les
>
>                 Best Regards,
>
>                 - Naiming
>
>                 Les
>
>         [email-masked] <mailto:[email-masked]>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 30 Apr 2017 19:57:28 +0000

Alex –

I agree with you – however the language in the draft is not nearly as specific as what you describe below.
If the draft is to promote use of reverse-metric to address IGP-LDP sync issues on a LAN it needs to include much of the language you suggest.

   Les

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Sunday, April 30, 2017 9:10 AM
To: Les Ginsberg (ginsberg); Naiming Shen (naiming)
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Hi Les,

I think that this is alternative to RFC 6138 and complement to RFC 5443. Per my understanding, it is supposed that only startup router is responsible for advertising Reverse metric. It also applies procedure from RFC 5443 (i.e. increases its forward metric). According to that, all other routers on the LAN will have high metric towards startup router. Startup router also has high metric towards LAN (per RFC 5443). At the same time routers on the LAN, except startup router, can use this LAN for transit traffic. I expect that other routers will not apply RFC 5443 on this LAN and will not advertise Reverse metric when new node appears on the LAN, unless for startup of their own interface to this LAN. To make this procedure reliable, other router can monitor metric over LAN towards startup router, and if it equals to 2^24-2 (assumed that Reverse metric value will be 2^24-2 for this application), they don't apply procedure from RFC 5443. Otherwise they fallback to RFC 5443 (DIS is not compatible to the draft and ignores Reverse metric). Once startup router has received EoL over all LDP sessions over LAN (or their synchronization timeouts have been expired), it could revert its forward metric back to configured one. Once it have sent EoL over all LDP sessions over LAN, it ceases advertisement of its Reverse metric.

Thank you.

   Les

From: Naiming Shen (naiming)
Sent: Thursday, April 27, 2017 5:33 PM
To: Alexander Okonnikov
Cc: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Hi Alex,

Sure. Will do. thanks.

- Naiming

Naiming,

Thank you.

Hi Alex,

thanks.
- Naiming

Les,

Thank you!

Alex –

   Les

Hi Les,

   Les

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Mon, 1 May 2017 00:46:26 +0000

Hi,

I agree too:-)

I added a ‘LDP/IGP sync case case’ in section 1 and moved the
Appendix-C into section 3, with those words:

3.5.  LDP/IGP Synchronization on LAN's

   As described in [RFC6138] when a new IS-IS node joins a broadcast
   network, it is unnecessary and sometimes even harmful to put IS-IS
   maximum link metric on all the nodes.  [RFC6138] proposes a solution
   to have the new node not advertising the adjacency towards the
   pseudo-node when it is not in a "cut-edge" position.

   With the introduction of Reverse Metric in this document, a simpler
   alternative solution to the above mentioned problem can be used.  The
   Reverse Metric allows the new node on the LAN to have the inbound
   metric value to be the maximum and this puts the link of this new
   node in the last resort position without impacting the other IS-IS
   nodes on the same LAN.

   Specifically, when IS-IS adjacencies are being established by the new
   node on the LAN, besides setting the maximum link metric value (2^24
   - 2) on the interface of the LAN for the IGP LDP synchronization as
   described in [RFC5443], it SHOULD advertise the maximum metric offset
   value in the Reverse Metric TLV in its IIH PDU to the LAN.  It SHOULD
   continue this advertisement until it completes all the LDP label
   binding exchanges with all the neighbors over this LAN, either by
   receiving the LDP End-of-LIB [RFC5919] for all the sessions or by
   exceeding the provisioned timeout value on the node.

Regards,
- Naiming

On Apr 30, 2017, at 12:57 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Alex –

   Les

Hi Les,

Thank you.

   Les

Hi Alex,

Sure. Will do. thanks.

- Naiming

Naiming,

Thank you.

Hi Alex,

thanks.
- Naiming

Les,

Thank you!

Alex –

   Les

Hi Les,

   Les

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 1 May 2017 02:06:03 +0000

Naiming –

Perfect!!

   Les

From: Naiming Shen (naiming)
Sent: Sunday, April 30, 2017 5:46 PM
To: Les Ginsberg (ginsberg); Alexander Okonnikov
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Hi,

I agree too:-)

Regards,
- Naiming

Alex –

   Les

Hi Les,

   Les

Hi Alex,

Sure. Will do. thanks.

- Naiming

Naiming,

Thank you.

Hi Alex,

thanks.
- Naiming

Les,

Thank you!

Alex –

   Les

Hi Les,

   Les

thanks.
- Naiming

Les,

thanks.
- Naiming

Naiming –

Thanx for the reply.
Inline – look for LES:

Les,

Naiming/Michael/Shane -

[NS->]

[NS->]

Section 2

[NS->]
Agreed.
[<-NS]

[NS->]

[NS->]

Section 3.5

[NS->]

[NS->]

[NS->]

   Les

Best Regards,
- Naiming

   Les