Subject: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 05 Dec 2018 11:11:34 -0800

Reviewer: Yoshifumi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

Summary: This document is almost ready for publication, but several points need
to be clarified.

1: In Section 1:
     "While this document does not specify how the performance information
     should be obtained, the
      measurement of delay SHOULD NOT vary significantly based upon the offered
      traffic load."

   It is not clear to me that why the measurement of delay should not vary
   here. Also, queuing delay might be useful info to infer path status. Could
   you elaborate the delays that the draft tries to capture?

2: In Section 1:
     "Thus, queuing delays SHOULD NOT be included in the delay measurement. "

   Is it clear for expected readers how to exclude queuing delays in their
   measurements? Don't we need to provide any guidances or references here?
   Also, what they should do if they cannot exclude it?

3: In Section 2:

     "All values (except residual bandwidth) MUST be calculated as rolling
     averages where the
      averaging period MUST be a configurable period of time."

   This requirement is a bit different from the following texts in Section 5:
   Also, does this mean only simple moving average must be used or any forms of
   moving average is acceptable?

    "The values advertised in all sub-TLVs (except min/max delay and
     residual bandwidth) MUST represent an average over a period or be
     obtained by a filter that is reasonably representative of an average.
     For example, a rolling average is one such filter."

4: In Section 4.3:

    "This sub-TLV advertises the average link delay variation between two
     directly connected IS-IS neighbors.  The delay variation advertised
     by this sub-TLV MUST be the delay from the local neighbor to the
     remote one (i.e., the forward-path latency)."

   Sorry.. I am not sure how to measure delay variation here. I think more
   explanation is needed. It seems that it is not variance as the unit is sec.

5: In Section 11:

    "The use of Link State PDU cryptographic authentication allows mitigation
    the risk of man-in-
     the-middle attack."

   When there is a risk for man-in-the-middle attack, don't we need more strong
   requirements for the use of security mechanisms?

Thanks,
--
Yoshi

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 6 Dec 2018 00:51:51 +0000

Yoshi -

Thanx for taking the time to review.

I can appreciate that this may the first time you have looked at RFC7810 - let alone the bis draft. As a result you have commented on content which is common to the bis draft and the RFC it is modifying (RFC 7810).

While your questions in isolation may be interesting, I believe they are out of scope for the review of the bis draft. What the bis draft is doing is addressing two modest errata - details of which can be found in https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03#appendix-A
Comments on content not related to those changes is out of scope.

If you have an interest in this topic and want to comment on the substance of RFC 7810 and its companion document for OSPF RFC 7471, I encourage you to do so. Note that all of your comments (save the one on Security) are also applicable to RFC 7471 - so any agreed upon modification would need to be made to both documents. But I do not want to even start discussing such changes in the context of reviewing the bis draft changes. I hope you can understand why.

As regards your Security comment, I am not sure I understand what you are suggesting. As IGP info is flooded hop-by-hop, man-in-the-middle attacks have to be able to insert themselves on an IGP enabled link. Use of cryptographic authentication prevents untrusted sources from being accepted - which is the point being made.

   Les

> -----Original Message-----
> From: Yoshifumi Nishida <[email-masked]>
> Sent: Wednesday, December 05, 2018 11:12 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 5 Dec 2018 20:40:56 -0600

Hi, Les,

On Wed, Dec 5, 2018 at 6:52 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> I can appreciate that this may the first time you have looked at RFC7810 -
> let alone the bis draft. As a result you have commented on content which is
> common to the bis draft and the RFC it is modifying (RFC 7810).
>
> While your questions in isolation may be interesting, I believe they are
> out of scope for the review of the bis draft. What the bis draft is doing
> is addressing two modest errata - details of which can be found in
> https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03#appendix-A
> If you have an interest in this topic and want to comment on the substance
> of RFC 7810 and its companion document for OSPF RFC 7471, I encourage you
> to do so. Note that all of your comments (save the one on Security) are
> also applicable to RFC 7471 - so any agreed upon modification would need to
> be made to both documents. But I do not want to even start discussing such
> changes in the context of reviewing the bis draft changes. I hope you can
> understand why.
>
> As regards your Security comment, I am not sure I understand what you are
> suggesting. As IGP info is flooded hop-by-hop, man-in-the-middle attacks
> have to be able to insert themselves on an IGP enabled link. Use of
> cryptographic authentication prevents untrusted sources from being accepted
> - which is the point being made.
>

I'm just making sure I understand this last point.

The text Yoshi flagged,

    "The use of Link State PDU cryptographic authentication allows
mitigation
    the risk of man-in-
     the-middle attack."

is saying "smart people would use Link State PDU cryptographic
authentication unless they have a reason to be OK with man-in-the-middle
attacks", but there's no normative requirement to use this mitigation
technique.

I think that's what Yoshi was asking about.

Is that the intent?

Thanks,

Spencer

p.s. Is there a missing word after "mitigation"?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 6 Dec 2018 05:08:28 +0000

Spencer –

The choice of whether to use cryptographic authentication or not is a deployment decision. It is not the place of this RFC (or any other IGP RFC) to require that a customer use authentication of any kind. However, in Security sections we do mention that the use of cryptographic authentication may well be prudent to avoid risks associated with the advertisements which the document is defining.

Make sense?

I agree there is an editorial issue.

“mitigation the risk” should be “mitigation of the risk”

I will address that.

   Les

From: Spencer Dawkins at IETF <[email-masked]>
Sent: Wednesday, December 05, 2018 6:41 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; IETF list <[email-masked]>; [email-masked]
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Hi, Les,

On Wed, Dec 5, 2018 at 6:52 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Yoshi -

The text Yoshi flagged,

is saying "smart people would use Link State PDU cryptographic authentication unless they have a reason to be OK with man-in-the-middle attacks", but there's no normative requirement to use this mitigation technique.

Is that the intent?

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Dec 2018 00:38:11 -0600

Hi, Les,

On Wed, Dec 5, 2018 at 11:08 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Spencer –
>
>
>
> The choice of whether to use cryptographic authentication or not is a
> deployment decision. It is not the place of this RFC (or any other IGP RFC)
> to require that a customer use authentication of any kind. However, in
> Security sections we do mention that the use of cryptographic
> authentication may well be prudent to avoid risks associated with the
> advertisements which the document is defining.
>
>
>
> Make sense?
>

Sure, and I'm not asking for an
https://tools.ietf.org/html/rfc6919#section-1 "MUST (BUT WE KNOW YOU
WON'T)" - and this is the second draft on this telechat where I've used
that link in my balloting discussion, so You Are Not Alone!

Thanks for helping me understand.

Spencer

> *From:* Spencer Dawkins at IETF <[email-masked]>
> *Sent:* Wednesday, December 05, 2018 6:41 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]; IETF list <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Tsv-art] Tsvart last call review of
> draft-ietf-lsr-isis-rfc7810bis-03
>
>
>
> Hi, Les,
>
>
>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 6 Dec 2018 09:55:25 -0800

On December 5, 2018 at 7:52:00 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

Les:

You are right in pointing out that the changes made to rfc7810 are the ones
mentioned in the appendix.  That was the motivation that originated this
work.

However, this document doesn’t just modify rfc7810, it formally declares it
Obsolete.  That indicates that we (the WG, etc.) are opening up the whole
document for review/comments…which obviously means that Yoshi’s comments
are not out of scope.  The WG didn’t change anything else (which is ok),
but the IETF Last Call exists to include cross-area review and to allow
others (e.g. non-WG participants) to comment.

In any case, it seems to me that Yoshi’s comments are clarifying questions
which may not require changes to the document itself. But I’ll leave that
discussion/decision to him and to the TSV ADs.

Note that if what is wanted (by the WG) is to Update rfc7810 (and not
Obsolete it), and constrain the text to be reviewed/commented on, then this
is not the right document.  That document would have contained only the
changes.  We’re still in time to change the direction.  I’m explicitly
cc’ing the lsr-chairs so they can make any needed clarification.

Thanks!

Alvaro.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 6 Dec 2018 13:30:36 -0800

Hi Les,

> Comments on content not related to those changes is out of scope.

Just to be clear, my comments on this draft were clarification questions
which won't request changes in the spec of the draft because I thought
there are a certain ambiguities in the draft.
But, if what you really mean is there is no ambiguities or confusions among
expected readers on the points I made, it makes a sense to me and I can
think I had unnecessary concerns.
However, I'm not fully sure about it yet.

For example, the draft mentions about delay variation and it seems to me
this term is a bit ambiguous. If expected readers can understand it means
(for example) mean deviation, I am fine with it.
But, in this case,I might want to see supportive comments on this view from
the community.
Or, if you can clarify that even if there are some discrepancies between
implementations it won't affect overall performance of the applications,  I
am also fine with it.

Anyway, I just tried to do my best to read and review the draft. I hope
not, but if the points I made don't make sense please let me know.
I would like to leave further decisions to ADs.

> - which is the point being made.

As Spencer already made my point clear (Thanks Spencer!), I was wondering
if we need a normative language here as the draft mentions these info can
be sensitive.
I was also wondering why the draft didn't mention encryption while it
conveys sensitive info.

Thanks,
--
Yoshi

> > Cc: [email-masked]; [email-masked];
> [email-masked]
> > Summary: This document is almost ready for publication, but several
> points
> > need
> > to be clarified.
> >
> > 1: In Section 1:

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Dec 2018 10:01:01 +0000

Alvaro –

I am not in agreement with your POV.

The work undertaken for this revision was very specifically to address Errata ID: 5293 (https://www.rfc-editor.org/errata_search.php?rfc=7810) . This was deemed critical because the format of several sub-TLVs was incorrectly specified and we learned that this resulted in an interoperability problem because some implementations chose to include the unneeded reserved field and used a sub-TLV length of 5 whereas other implementations omitted the Reserved field and used the specified length of 4. We wanted to fasttrack this change to avoid further interoperability issues.

Just prior to preparing for last call Errata ID: 5486 (https://www.rfc-editor.org/errata/eid5486) was posted. As this was only an editorial change we decided to address that as well.

There was never an intent to review/alter any other portion of the document. Rather we constrained the changes precisely so that we could publish a corrected version of the RFC ASAP.

Your argument that since we are obsoleting RFC 7810 the entire document is fair game is not consistent with the agreed upon scope of the changes.
The WG never agreed to open up the document for general revision and I do not believe it should be within the purview of IESG review to alter the scope of the work the WG agreed to take on.

Suggesting that rather than issue a new version of RFC7810 we should issue a smaller document only with the corrections is a viable option – but IMO makes an unnecessary mess of things.

As an aside, it is quite frustrating to me that it is almost 9 months since this work was started and we still have yet to complete it. Taking this long to publish a non-controversial and much needed editorial revision is much too long. Though I appreciate we are getting closer, I think this does not speak well of us as an organization. Opening up the document to general review can do nothing but delay this further – making it more likely that additional non-interoperable implementations may be written.

Yoshi (or any other IETF participant) is free at any time to raise questions about RFC7810/RFC7471 and the WG can decide whether it agrees that changes are needed. But that is not within the scope of this work.

   Les

From: Alvaro Retana <[email-masked]>
Sent: Thursday, December 06, 2018 9:55 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Christian Hopps <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Yoshifumi Nishida <[email-masked]>; [email-masked]
Subject: RE: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

On December 5, 2018 at 7:52:00 PM, Les Ginsberg (ginsberg) ([email-masked]<mailto:[email-masked]>) wrote:

Les:

You are right in pointing out that the changes made to rfc7810 are the ones mentioned in the appendix.  That was the motivation that originated this work.

However, this document doesn’t just modify rfc7810, it formally declares it Obsolete.  That indicates that we (the WG, etc.) are opening up the whole document for review/comments…which obviously means that Yoshi’s comments are not out of scope.  The WG didn’t change anything else (which is ok), but the IETF Last Call exists to include cross-area review and to allow others (e.g. non-WG participants) to comment.

In any case, it seems to me that Yoshi’s comments are clarifying questions which may not require changes to the document itself. But I’ll leave that discussion/decision to him and to the TSV ADs.

Note that if what is wanted (by the WG) is to Update rfc7810 (and not Obsolete it), and constrain the text to be reviewed/commented on, then this is not the right document.  That document would have contained only the changes.  We’re still in time to change the direction.  I’m explicitly cc’ing the lsr-chairs so they can make any needed clarification.

Thanks!

Alvaro.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Dec 2018 20:06:10 +0000

Yoshi –

I’ll try to provide some response to your comments. I preface this by saying:

1)I was not an author on RFC 7810. It is possible that my remarks do not accurately reflect the thinking of the original authors. If so, I hope one or more of them will find the time to correct me.

2)The intent of this bis draft was solely to correct the editorial issue which resulted in confusion and interoperability issues associated with the sub-TLV encoding for the three bandwidth TLVs. There are implementations based on RFC 7810 and no one to my knowledge has expressed confusion regarding how to take the measurements – nor has anyone expressed concern as to any omissions in the parameters advertised. Therefore we have no reason to alter the existing text in these areas.

Responses inline.

From: Yoshifumi Nishida <[email-masked]>
Sent: Thursday, December 06, 2018 1:31 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Hi Les,

On Wed, Dec 5, 2018 at 4:51 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Yoshi -

Just to be clear, my comments on this draft were clarification questions which won't request changes in the spec of the draft because I thought there are a certain ambiguities in the draft.
But, if what you really mean is there is no ambiguities or confusions among expected readers on the points I made, it makes a sense to me and I can think I had unnecessary concerns.
However, I'm not fully sure about it yet.

For example, the draft mentions about delay variation and it seems to me this term is a bit ambiguous. If expected readers can understand it means (for example) mean deviation, I am fine with it.
But, in this case,I might want to see supportive comments on this view from the community.
Or, if you can clarify that even if there are some discrepancies between implementations it won't affect overall performance of the applications,  I am also fine with it.

Anyway, I just tried to do my best to read and review the draft. I hope not, but if the points I made don't make sense please let me know.
I would like to leave further decisions to ADs.

As Spencer already made my point clear (Thanks Spencer!), I was wondering if we need a normative language here as the draft mentions these info can be sensitive.
I was also wondering why the draft didn't mention encryption while it conveys sensitive info.

[Les:] IS-IS runs directly over Layer 2 and does not support encryption.

Thanks,
--
Yoshi

> From: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]> if you reply to or forward this review.
>

[Les:] The measurements are for the performance of the link – not the impact queueing delay may have.
This seems consistent with the directly referenced RFC6374<https://tools.ietf.org/html/rfc6374> and the indirectly referenced RFC2679<https://tools.ietf.org/html/rfc2679>

>    Also, what they should do if they cannot exclude it?

[Les:] This is explicitly stated as out of scope. From the abstract:

“Note that this document only covers the mechanisms with which
   network-performance information is distributed.  The mechanisms for
   measuring network performance or acting on that information, once
   distributed, are outside the scope of this document.”

>      For example, a rolling average is one such filter."
[Les:] My interpretation is that Section 2 is summarizing a requirement which is presented with some additional detail in Section 5.

>    explanation is needed. It seems that it is not variance as the unit is sec.
[Les:] Definition of how to do this measurement can be found in the referenced https://tools.ietf.org/html/rfc6374#section-2.5
HTH
   Les

---

From: John E Drake <[email-masked]>
Date: Fri, 7 Dec 2018 20:12:31 +0000

Hi,

The answers that Les gives, below, to Yoshifumi are completely correct.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Friday, December 7, 2018 3:06 PM
To: Yoshifumi Nishida <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Yoshi –

Responses inline.

From: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 06, 2018 1:31 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [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: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Hi Les,

While your questions in isolation may be interesting, I believe they are out of scope for the review of the bis draft. What the bis draft is doing is addressing two modest errata - details of which can be found in https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03#appendix-A<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dlsr-2Disis-2Drfc7810bis-2D03-23appendix-2DA&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=cshx0Rg6vOrONpG_nGle507LJUTtEDfYrQEJBDjhwcU&s=t_Fn06RaSxZd_HwovODc65u6de0d-HaN38BUBv5Ok-k&e=>
Comments on content not related to those changes is out of scope.

Thanks,
--
Yoshi

[Les:] The measurements are for the performance of the link – not the impact queueing delay may have.
This seems consistent with the directly referenced RFC6374<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6374&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=cshx0Rg6vOrONpG_nGle507LJUTtEDfYrQEJBDjhwcU&s=gHJjgG_HmzZHQHI_iIagYl7TZDAwk-iWnVrBzY6r_6A&e=> and the indirectly referenced RFC2679<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc2679&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=cshx0Rg6vOrONpG_nGle507LJUTtEDfYrQEJBDjhwcU&s=7_3LTjsXrPMPlBh3n54mTbU1vRsmZURjEfG2BbSEl-I&e=>

>    explanation is needed. It seems that it is not variance as the unit is sec.
[Les:] Definition of how to do this measurement can be found in the referenced https://tools.ietf.org/html/rfc6374#section-2.5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6374-23section-2D2.5&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=cshx0Rg6vOrONpG_nGle507LJUTtEDfYrQEJBDjhwcU&s=A8pva4zdoNgvED7ANXhHgRVx8SeVI-HDybIATpANXNM&e=>
HTH
   Les

---

From: stefano previdi <[email-masked]>
Date: Fri, 7 Dec 2018 11:37:09 +0100

Hi All,

> On Dec 7, 2018, at 11:01 AM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Alvaro –
>  

correct. This also was pointed out at the time of editing and submission of this draft. The WG agreed to move on without res-pinning th whole reviwe process exactly for the reasons above.

> As an aside, it is quite frustrating to me that it is almost 9 months since this work was started and we still have yet to complete it. Taking this long to publish a non-controversial and much need…

+1.

Thanks.
s.

> On December 5, 2018 at 7:52:00 PM, Les Ginsberg (ginsberg) ([email-masked]) wrote:
>  
> Les:
>