Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

From: Christian Hopps <[email-masked]>
Date: Wed, 15 Nov 2017 17:43:24 -0500

The authors have asked for and we are starting a WG Last Call on

  https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/

which will last an extended 3 weeks to allow for IETF100.

Thanks,
Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 24 Nov 2017 23:05:05 +0000

Hi, 

I support publication of the subject document. I do have comments.

   1. Why do you call the reverse-metricn field, “Metric Offset”? This
sounds like a remnant of some bad 20th century CLI….
   2. Please split the single sentence description immediately following
figure 1 into multiple sentences. Maybe just refer to “Elements of
Procedure” sections rather than one incomprehensible sentence.
   3. Pervasive editorial comment, the plural of acronyms is does NOT have
an apostrophe. For example, it is TLVs, not TLV’s.

Thanks,
Acee

On 11/15/17, 5:43 PM, "Isis-wg on behalf of Christian Hopps"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Mon, 27 Nov 2017 21:38:41 +0000

Hi Acee,

thanks for the comments. replies inline with <NS>…</NS>

On Nov 24, 2017, at 3:05 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

<NS>
the draft used to have the field as just ‘Metric’, since version 06, we responded
to the comments:

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.

which is a good point I think. do you think there is an alternative name we
can use in replacing the ‘offset’ here?
</NS>

<NS>
will change those.

thanks.
- Naiming
</NS>

Thanks,
Acee

On 11/15/17, 5:43 PM, "Isis-wg on behalf of Christian Hopps"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Chris.

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

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 27 Nov 2017 23:32:48 +0000

Hi Naiming,

From: "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 27, 2017 at 4:38 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Acee,

Hi,

<NS>

Section 2

How about just calling it the “Reverse Metric”?

Thanks,
Acee

<NS>
will change those.

thanks.
- Naiming
</NS>

Thanks,
Acee

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 27 Nov 2017 23:53:01 +0000

Acee –

The IS-IS draft is more flexible in this regard than the OSPF equivalent (https://tools.ietf.org/html/draft-ietf-ospf-link-overload-10).

In the IS-IS draft the text states:

“The Metric Offset field contains a 24-bit unsigned integer of an IS-
   IS metric that a neighbor SHOULD add to the existing, configured
   "default metric" contained within its IS Neighbors TLV…”

This allows that the operator could choose to set the neighbor metric to something other than “max-metric-1”.

Contrast this with the OSPF Draft which states:

“The node that has the link to be taken out of service MUST set metric
   of the link to MaxLinkMetric (0xffff)…”

The text in the IS-IS draft needs to remain as it is.

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 27, 2017 3:33 PM
To: Naiming Shen (naiming) <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Naiming,

Hi Acee,

Hi,

<NS>

Section 2

Thanks,
Acee

<NS>
will change those.

thanks.
- Naiming
</NS>

Thanks,
Acee

Thanks,
Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Nov 2017 03:16:25 +0000

Hi Les,

I guess we know the origin of the term “metric-offset” ;^)

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 27, 2017 at 6:53 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Acee –

Why are you comparing this draft to OSPF Link Overload? If you know the metric value, you don’t need any metric field (as is the case for OSPF Link Overload).

The argument for keeping the text as is is flawed. Using "metric” or “reverse metric” for the identifier of the field would simply align it with the identifier for the advertising TLV. In the context of a reverse metric (the advertised TLV), it is not a metric offset even though it is added to the existing metric in the SPF computation.

Thanks,
Acee

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 27, 2017 3:33 PM
To: Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Naiming,

Hi Acee,

Hi,

<NS>

Section 2

Thanks,
Acee

<NS>
will change those.

thanks.
- Naiming
</NS>

Thanks,
Acee

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 Nov 2017 04:12:58 +0000

Acee –

From: Acee Lindem (acee)
Sent: Monday, November 27, 2017 7:16 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Naiming Shen (naiming) <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Les,

[Les:] Always good to know who to blame. ☺

Acee –

[Les:] The draft defines the usage of the metric value advertised in the Reverse Metric TLV as a value that

“a neighbor SHOULD add to the existing, configured  default metric”

This definition was the same even in earlier versions (V5 and earlier) where the name of the field was “metric” rather than “metric offset”.

I always thought the purpose of defining it as an offset was to prevent an operator from accidentally making the metric smaller than the value configured on the neighbor. You seem to be arguing that this is the wrong way to do things – that you should always send an absolute value – but this does mean there is some risk that the value the neighbor advertised upon receipt of the Reverse Metric TLV could be smaller than it currently is. This could be prevented by normative language in the draft to say the neighbor should ignore such cases.

The authors should comment on whether they would prefer to move to your proposal. Personally I see no need to change the draft.
But, in terms of the best name for the field in the TLV I think it should represent how that value is used. Currently that is as an “offset”. If you convince the authors to change things and make the value an absolute then I would agree the term “metric” would be better. All I want is clarity and consistency.

    Les

Thanks,
Acee

   Les

Hi Naiming,

Hi Acee,

Hi,

<NS>

Section 2

Thanks,
Acee

<NS>
will change those.

thanks.
- Naiming
</NS>

Thanks,
Acee

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 Nov 2017 04:28:16 +0000

I support publication of this document.

For those of you who have followed this draft over the years, you will know that I have expressed concerns as to whether this is needed and/or is an appropriate way of achieving the desired behaviors. 
However, it is clear that this is seen as useful by operators, and I think with the addition of other use cases (mobility, spine-leaf, LDP-IGP sync), handling of TE, security discussion, and more complete deployment discussion this draft does provide a significant and useful mechanism and I am happy to support it.

   Les

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian
> Hopps
> Sent: Wednesday, November 15, 2017 2:43 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
> 
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Nov 2017 13:48:08 +0000

Hi Les,

Date: Monday, November 27, 2017 at 11:12 PM

Acee –

From: Acee Lindem (acee)
Sent: Monday, November 27, 2017 7:16 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Les,

Acee –

The reason I believe that “metric” or “reverse-metric” are better terms Is that they define what the value is rather than how it is used in the primary use case. In the context of the Reverse Metric TLV (where the value is advertised), it is simply the reverse-metric as opposed to any kind of offset. Note that “OSPF Two-Part Metric” (RFC 8042) simply uses the term “MT-metric”.

Fine with me as well.

Thanks,
Acee

    Les

Thanks,
Acee

   Les

Hi Naiming,

Hi Acee,

Hi,

<NS>

Section 2

Thanks,
Acee

<NS>
will change those.

thanks.
- Naiming
</NS>

Thanks,
Acee

Thanks,
Chris.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 29 Nov 2017 07:54:50 +0000

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?

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-masked]] On Behalf Of Christian Hopps
Sent: 16 November 2017 04:13
To: [email-masked]
Cc: [email-masked]
Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Thanks,
Chris.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 29 Nov 2017 22:47:04 +0000

Hi Ketan,

thanks for the support and comments. some clarification inline,

> On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) <[email-masked]> wrote:
> 
> Hello,
> 

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