Re: [Lsr] I-D Action: draft-wu-lsr-pce-discovery-security-support-01.txt

[Qin Wu]

v-01 has just been posted to address received comments so far.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-wu-lsr-pce-discovery-security-support-01

-Qin
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2018年11月29日 14:29
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-wu-lsr-pce-discovery-security-support-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : IGP extension for PCEP security capability support in 
the PCE discovery
Authors : Diego R. Lopez
  Qin Wu
  Dhruv Dhody
  Michael Wang
  Daniel King
Filename: draft-wu-lsr-pce-discovery-security-support-01.txt
Pages   : 10
Date: 2018-11-28

Abstract:
   When a Path Computation Element (PCE) is a Label Switching Router
   (LSR) participating in the Interior Gateway Protocol (IGP), or even a
   server participating in IGP, its presence and path computation
   capabilities can be advertised using IGP flooding.  The IGP
   extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
   to advertise path computation capabilities using IGP flooding for
   OSPF and IS-IS respectively.  However these specifications lack a
   method to advertise PCEP security (e.g., Transport Layer
   Security(TLS), TCP Authentication Option (TCP-AO)) support
   capability.

   This document proposes new capability flag bits for PCE-CAP-FLAGS
   sub-TLV that can be announced as attribute in the IGP advertisement
   to distribute PCEP security support information.  In addition, this
   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
   ID or Key Chain Name Sub-TLV to support TCP AO security capability.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wu-lsr-pce-discovery-security-support/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-01
https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wu-lsr-pce-discovery-security-support-01


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Last Call: (IS-IS Traffic Engineering (TE) Metric Extensions) to Proposed Standard

[The IESG]

The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IS-IS Traffic Engineering (TE) Metric
Extensions'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-12-12. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   In certain networks, such as, but not limited to, financial
   information networks (e.g., stock market data providers), network-
   performance criteria (e.g., latency) are becoming as critical to
   data-path selection as other metrics.

   This document describes extensions to IS-IS Traffic Engineering
   Extensions (RFC 5305) such that network-performance information can
   be distributed and collected in a scalable fashion.  The information
   distributed using IS-IS TE Metric Extensions can then be used to make
   path-selection decisions based on network performance.

   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.

   This document obsoletes RFC 7810.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3257/
   https://datatracker.ietf.org/ipr/3259/





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[Alvaro Retana]

On November 28, 2018 at 5:46:08 PM, Les Ginsberg (ginsberg) (
ginsb...@cisco.com) wrote:

Les:

Hi!

As lead author on rfc7810bis I am happy to modify the language to be
consistent with RFC7471. That seems like the far easier pathway so long as
we have your assurance (which it seems we do) that this will not unduly
delay progress of rfc7810bis.

I already requested the start of the IETF LC for rfc7810bis.  I don’t think
the potential changes we’re talking about will be that significant to delay.

I do find that the fact that you raised this issue in the context of
draft-ietf-idr-te-pm-bgp rather confusing (though I can appreciate that it
was your review of the idr draft that brought the discrepancy to your
attention).

Yes, draft-ietf-idr-te-pm-bgp was simply first on my queue…so I read it
first.

It would have been less confusing – at least to me – if you had raised this
point in a separate email regarding rfc7810bis.

https://mailarchive.ietf.org/arch/msg/lsr/92-08uCr6-ctnRU9i3FHA-ucFEw

Thanks!

Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[Les Ginsberg (ginsberg)]

Alvaro –

As lead author on rfc7810bis I am happy to modify the language to be consistent 
with RFC7471. That seems like the far easier pathway so long as we have your 
assurance (which it seems we do) that this will not unduly delay progress of 
rfc7810bis.

I do find that the fact that you raised this issue in the context of 
draft-ietf-idr-te-pm-bgp rather confusing (though I can appreciate that it was 
your review of the idr draft that brought the discrepancy to your attention).
It would have been less confusing – at least to me – if you had raised this 
point in a separate email regarding rfc7810bis.

That said, it is good to have caught this before publication. I will publish an 
rfc7810bis update in the next couple of days.

   Les


From: Alvaro Retana 
Sent: Wednesday, November 28, 2018 2:35 PM
To: John Scudder ; draft-ietf-lsr-isis-rfc7810...@ietf.org
Cc: Hares Susan ; idr-cha...@ietf.org; 
draft-ietf-idr-te-pm-...@ietf.org; idr@ietf. org ; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: Available Bandwidth erratum 5486 [was: Re: AD Review of 
draft-ietf-idr-te-pm-bgp-14]

I am explicitly copying the authors of rfc7810bis to get them involved in this 
discussion.  Also cc’d lsr-chairs.

Even if the two versions are algebraically identical, and because the 
definitions in draft-ietf-idr-te-pm-bgp depend on *both* documents, I would 
prefer it if the text was the same to avoid any confusion.  We are still in 
time to make changes to either rfc7471 (erratum) or rfc7810bis.

Thanks!

Alvaro.


On November 28, 2018 at 5:26:06 PM, John Scudder 
(j...@juniper.net) wrote:
Ah, I was looking at an old version of 7810bis, sorry about that.

ISTM that:

- if the two versions are actually algebraically identical (as I speculated but 
do not insist) then it would be nicer to adopt the "available bandwidth is 
defined to be the sum of the component link available bandwidths" version since 
it matches the language in RFC 7471 and is less confusing that way, but if 
they're logically identical it doesn't rally matter.
- if John Drake is correct in his reply that the "available bandwidth is 
defined to be the sum of the component link available bandwidths" is correct 
(implying the other version isn't, for some reason), then 7810bis is wrong and 
needs to be changed.
- If 7810bis is correct, and John is wrong, then there needs to be an erratum 
against RFC 7471.

I think that covers the universe of possibilities. I still don't know which is 
right, though.

No additional charge,

--John
On Nov 28, 2018, at 5:15 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

John:

Hi!

I should have pointed to the current version of rfc7810bis [1], which now reads:

Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 
4.5)
 minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link residual bandwidths (see Section 
4.5)
 minus the sum of the

   measured bandwidth used for the actual forwarding of non-RSVP-TE

   label switched path packets on all component links.
This version gets rid of the duplication and uses “residual”.  Because it’s 
been through WGLC I am assuming it is correct.  If not, please let me know 
*now*, as I am about to start the IETF LC.

Thanks!

Alvaro.

[1] 
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02



On November 28, 2018 at 4:33:54 PM, John Scudder 
(j...@juniper.net) wrote:
+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

[major] AFAICT, Available Bandwidth is the only definition that is different 
between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The difference 
comes from the correction made to address 

[Lsr] AD Review of draft-ietf-lsr-isis-rfc7810bis-02

[Alvaro Retana]

Dear authors:

Thanks for taking on this work!!

I have just a couple of comments.

(1) There are too many authors in the front page.  I know that the list was
cut prior to rfc7810 being processed, and that Les was added to hold the
pen on this revision, so I'll let this one proceed.  Just one thing: please
group the authors by affiliation (which will reduce the size of the header).

(2) Both rfc7471 and rfc7810 can be Informative references.

(3) There's an active thread related to the definition of Available
Bandwidth [1].  Please keep an eye on it and participate as needed.

I don't think the ongoing discussion is a showstopper at this point.  I am
starting the IETF Last Call.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/lsr/zOdpuIbCViJToCsC9mNnRmoEiQw
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[Alvaro Retana]

I am explicitly copying the authors of rfc7810bis to get them involved in
this discussion.  Also cc’d lsr-chairs.

Even if the two versions are algebraically identical, and because the
definitions in draft-ietf-idr-te-pm-bgp depend on *both* documents, I would
prefer it if the text was the same to avoid any confusion.  We are still in
time to make changes to either rfc7471 (erratum) or rfc7810bis.

Thanks!

Alvaro.

On November 28, 2018 at 5:26:06 PM, John Scudder (j...@juniper.net) wrote:

Ah, I was looking at an old version of 7810bis, sorry about that.

ISTM that:

- if the two versions are actually algebraically identical (as I speculated
but do not insist) then it would be nicer to adopt the "available bandwidth
is defined to be the sum of the component link available bandwidths"
version since it matches the language in RFC 7471 and is less confusing
that way, but if they're logically identical it doesn't rally matter.
- if John Drake is correct in his reply that the "available bandwidth is
defined to be the sum of the component link available bandwidths" is
correct (implying the other version isn't, for some reason), then 7810bis
is wrong and needs to be changed.
- If 7810bis is correct, and John is wrong, then there needs to be an
erratum against RFC 7471.

I think that covers the universe of possibilities. I still don't know which
is right, though.

No additional charge,

--John

On Nov 28, 2018, at 5:15 PM, Alvaro Retana  wrote:

John:

Hi!

I should have pointed to the current version of rfc7810bis [1], which now
reads:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5
)
minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link residual bandwidths (see Section 4.5
)
minus the sum of the
   measured bandwidth used for the actual forwarding of non-RSVP-TE
   label switched path packets on all component links.

This version gets rid of the duplication and uses “residual”.  Because it’s
been through WGLC I am assuming it is correct.  If not, please let me know
*now*, as I am about to start the IETF LC.

Thanks!

Alvaro.

[1] https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02



On November 28, 2018 at 4:33:54 PM, John Scudder (j...@juniper.net) wrote:

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana  wrote:

[major] AFAICT, Available Bandwidth is the only definition that is
different between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The
difference comes from the correction made to address this report [1].
Instead of trying to fix the definition here, I think that a similar report
should be filed against rfc7471.  Please submit it and I will approve.

[1] https://www.rfc-editor.org/errata/eid5486



Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810
paragraph in question:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  *For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched 

Re: [Lsr] [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[John E Drake]

Alvaro,

As I said, John’s suggestion is correct and it does match 7471, which is also 
correct.

Yours Irrespectively,

John

From: Idr  On Behalf Of Alvaro Retana
Sent: Wednesday, November 28, 2018 5:16 PM
To: John Scudder 
Cc: lsr@ietf.org; idr-cha...@ietf.org; draft-ietf-idr-te-pm-...@ietf.org; Hares 
Susan ; idr@ietf. org 
Subject: Re: [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of 
draft-ietf-idr-te-pm-bgp-14]

John:

Hi!

I should have pointed to the current version of rfc7810bis [1], which now reads:

   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 
4.5)
 minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link residual bandwidths (see Section 
4.5)
 minus the sum of the

   measured bandwidth used for the actual forwarding of non-RSVP-TE

   label switched path packets on all component links.
This version gets rid of the duplication and uses “residual”.  Because it’s 
been through WGLC I am assuming it is correct.  If not, please let me know 
*now*, as I am about to start the IETF LC.

Thanks!

Alvaro.

[1] 
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02


On November 28, 2018 at 4:33:54 PM, John Scudder 
(j...@juniper.net) wrote:
+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

[major] AFAICT, Available Bandwidth is the only definition that is different 
between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The difference 
comes from the correction made to address this report [1].  Instead of trying 
to fix the definition here, I think that a similar report should be filed 
against rfc7471.  Please submit it and I will approve.

[1] 
https://www.rfc-editor.org/errata/eid5486

Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810 
paragraph in question:


Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

It seems obvious that there was a cut-and-paste problem or similar, since the 
same sentence is duplicated with minor changes. But the erratum leaves the 
duplication! The erratum wants it to be:


Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link (residual) bandwidths minus the measured 

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[John Scudder]

Ah, I was looking at an old version of 7810bis, sorry about that.

ISTM that:

- if the two versions are actually algebraically identical (as I speculated but 
do not insist) then it would be nicer to adopt the "available bandwidth is 
defined to be the sum of the component link available bandwidths" version since 
it matches the language in RFC 7471 and is less confusing that way, but if 
they're logically identical it doesn't rally matter.
- if John Drake is correct in his reply that the "available bandwidth is 
defined to be the sum of the component link available bandwidths" is correct 
(implying the other version isn't, for some reason), then 7810bis is wrong and 
needs to be changed.
- If 7810bis is correct, and John is wrong, then there needs to be an erratum 
against RFC 7471.

I think that covers the universe of possibilities. I still don't know which is 
right, though.

No additional charge,

--John

On Nov 28, 2018, at 5:15 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

John:

Hi!

I should have pointed to the current version of rfc7810bis [1], which now reads:

   Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 
4.5)
 minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link residual bandwidths (see Section 
4.5)
 minus the sum of the
   measured bandwidth used for the actual forwarding of non-RSVP-TE
   label switched path packets on all component links.


This version gets rid of the duplication and uses “residual”.  Because it’s 
been through WGLC I am assuming it is correct.  If not, please let me know 
*now*, as I am about to start the IETF LC.

Thanks!

Alvaro.

[1] 
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02


On November 28, 2018 at 4:33:54 PM, John Scudder 
(j...@juniper.net) wrote:

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

[major] AFAICT, Available Bandwidth is the only definition that is different 
between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The difference 
comes from the correction made to address this report [1].  Instead of trying 
to fix the definition here, I think that a similar report should be filed 
against rfc7471.  Please submit it and I will approve.

[1] 
https://www.rfc-editor.org/errata/eid5486

Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810 
paragraph in question:


Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.


It seems obvious that there was a cut-and-paste problem or similar, since the 
same sentence is duplicated with minor changes. But the erratum leaves the 
duplication! The erratum wants it to be:


Available Bandwidth: This field carries the available 

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[Alvaro Retana]

John:

Hi!

I should have pointed to the current version of rfc7810bis [1], which now
reads:

   Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5
)
minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link residual bandwidths (see Section 4.5
)
minus the sum of the
   measured bandwidth used for the actual forwarding of non-RSVP-TE
   label switched path packets on all component links.

This version gets rid of the duplication and uses “residual”.  Because it’s
been through WGLC I am assuming it is correct.  If not, please let me know
*now*, as I am about to start the IETF LC.

Thanks!

Alvaro.

[1] https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-02

On November 28, 2018 at 4:33:54 PM, John Scudder (j...@juniper.net) wrote:

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana  wrote:

[major] AFAICT, Available Bandwidth is the only definition that is
different between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The
difference comes from the correction made to address this report [1].
Instead of trying to fix the definition here, I think that a similar report
should be filed against rfc7471.  Please submit it and I will approve.

[1] https://www.rfc-editor.org/errata/eid5486



Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810
paragraph in question:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  *For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.*


It seems obvious that there was a cut-and-paste problem or similar, since
the same sentence is duplicated with minor changes. But the erratum leaves
the duplication! The erratum wants it to be:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  *For a bundled
   link, available bandwidth is defined to be the sum of the component
   link (residual) bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.
*


So the proposed "fix" is to leave the sentence duplicated, but change
"available" to "(residual)" in the first copy? I don't think that could
possibly be right. Just eyeballing it, it seems to me as though the correct
fix would be to change the paragraph to be:

Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.


in which case it would match RFC 7471. Or possibly:

Available Bandwidth: This field carries the available 

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

[John E Drake]

Hi,

Comments inline

Yours Irrespectively,

John

From: Idr  On Behalf Of John Scudder
Sent: Wednesday, November 28, 2018 4:34 PM
To: Alvaro Retana 
Cc: lsr@ietf.org; idr@ietf. org ; 
draft-ietf-idr-te-pm-...@ietf.org; Hares Susan ; 
idr-cha...@ietf.org
Subject: [Idr] Available Bandwidth erratum 5486 [was: Re: AD Review of 
draft-ietf-idr-te-pm-bgp-14]

+lsr to the cc

Hi Alvaro,

On Nov 28, 2018, at 4:01 PM, Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:

[major] AFAICT, Available Bandwidth is the only definition that is different 
between rfc7810/draft-ietf-lsr-isis-rfc7810bis and rfc7471.  The difference 
comes from the correction made to address this report [1].  Instead of trying 
to fix the definition here, I think that a similar report should be filed 
against rfc7471.  Please submit it and I will approve.

[1] 
https://www.rfc-editor.org/errata/eid5486

Maybe I'm missing something but isn't that erratum all wrong?

Here is why I think so. I agree that there is a problem with the RFC 7810 
paragraph in question:


   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

It seems obvious that there was a cut-and-paste problem or similar, since the 
same sentence is duplicated with minor changes. But the erratum leaves the 
duplication! The erratum wants it to be:


Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link (residual) bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

So the proposed "fix" is to leave the sentence duplicated, but change 
"available" to "(residual)" in the first copy? I don't think that could 
possibly be right. Just eyeballing it, it seems to me as though the correct fix 
would be to change the paragraph to be:


   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.



[JD]  John's suggestion, above, is correct.

in which case it would match RFC 7471. Or possibly:


   Available Bandwidth: This field carries the available bandwidth on a

   link, forwarding adjacency, or bundled link in IEEE floating-point

   format with units of bytes per second.  For a link or forwarding

   adjacency, available bandwidth is defined to be residual bandwidth

   (see Section 4.5) minus the measured bandwidth used for the actual

   forwarding of non-RSVP-TE label switched path packets.  For a bundled

   link, available bandwidth is defined to be the sum of the component

   link available residual bandwidths minus the measured bandwidth used for the

   actual forwarding of non-RSVP-TE label switched path packets.  For a

   bundled link, available bandwidth is defined to be the sum of the

   component link available bandwidths.

I have no idea which of these is right, but the erratum can't be right. 
Naively, they look 

[Lsr] IETF 103 LSR Meeting Minutes

[Acee Lindem (acee)]

All,
I have posted the meeting minutes from the IETF LSR meeting in Bangkok. Thanks 
to Yingzhen Qu for taking them!

https://datatracker.ietf.org/meeting/103/materials/minutes-103-lsr-00

As you can see, we have a lot of drafts to discuss between IETFs.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06

[Padmadevi Pillay Esnault]

Dear Alvaro

Thank you for your review.

We will go through the comments and work on them.

Thanks
Padma on behalf of my co-authors

On 11/28/18, 7:53 AM, "Alvaro Retana"  wrote:

Dear authors:

I just finished reading this document.  Even though it is relatively short,
I have significant concerns and I think it needs more work.  Please take a
look at the detailed comments in-line below -- I'm highlighting some of the
issues here.

(1) What is the Update to rfc2328?  Please be specific in both the Abstract
and the Introduction to indicate how rfc2328 is Updated.  Also, see my
question about rfc6987 in §6.

(2) Operational/Deployment Considerations.  There are several places
(specially in §3) where the specification offers a choice (e.g. by using
MAY).  Some of those choices would be better informed if there was a
discussion of the considerations behind them.  Please take a look at
rfc5706 (specially §2).  Either a discussion close to where the behavior is
specified or a separate section is ok.  Please also keep migration in mind
(see comments in §5).

(3) Both the IANA and Security Considerations sections need more details.


I will wait for them to be addressed before starting the IETF Last Call.

Thanks!

Alvaro.


[The line numbers come from idnits.]

...
11H-bit Support for OSPFv2
12 draft-ietf-ospf-ospfv2-hbit-06

[nit] Please make the title more descriptive.  "non-transit router", "host
mode", etc. come to mind.


14 Abstract

16   OSPFv3 defines an option bit for router-LSAs known as the R-bit in
17   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
18   OSPF topology flooding, however it will not be used as a transit
19   router.  In such cases, other routers in the OSPFv3 routing domain
20   only install routes to allow local traffic delivery.  This document
21   defines the H-bit functionality to prevent other OSPFv2 routers from
22   using the router for transit traffic in OSPFv2 routing domains as
23   described in RFC 2328.  This document updates RFC 2328.

[minor] Describing the functionality in terms of OSPFv2 would have been
nice.  IOW, there's no need (in the Abstract) to force the reader to go
figure out what OSPFv3 already did to decide if it's worth reading this
document or not.

[major] What is the Update to rfc2328?  Please be specific, both here and
in the Introduction: don't just mention the section updated, but (more
important) what is the update about.  "This document updates rfc2328 by
assigning a bit...changing the SPF process...creating a registry..."
 All/none/something else?

Note that the answer to "what is the update?" doesn't have to be all.  I
think that the registry creation is a must.  But Updating because of the
SPF changes means that you expect an rfc2328 implementation to consider the
H-bit when running SPF.  I think you really mean that implementations of
this document (i.e. not all rfc2328 implementations) have to use the
modified SPF.  That is my guess...please consider the answer carefully.


...
42 Copyright Notice

44   Copyright (c) 2018 IETF Trust and the persons identified as the
45   document authors.  All rights reserved.

47   This document is subject to BCP 78 and the IETF Trust's Legal
48   Provisions Relating to IETF Documents
49   (https://trustee.ietf.org/license-info) in effect on the date of
50   publication of this document.  Please review these documents
51   carefully, as they describe your rights and restrictions with respect
52   to this document.  Code Components extracted from this document must
53   include Simplified BSD License text as described in Section 4.e of
54   the Trust Legal Provisions and are provided without warranty as
55   described in the Simplified BSD License.

57   This document may contain material from IETF Documents or IETF
58   Contributions published or made publicly available before November
59   10, 2008.  The person(s) controlling the copyright in some of this
60   material may not have granted the IETF Trust the right to allow
61   modifications of such material outside the IETF Standards Process.
62   Without obtaining an adequate license from the person(s) controlling
63   the copyright in such materials, this document may not be modified
64   outside the IETF Standards Process, and derivative works of it may
65   not be created outside the IETF Standards Process, except to format
66   it for publication as an RFC or to translate it into languages other
67   than English.

[major] As far as I can tell, the first version of
draft-keyupate-ospf-ospfv2-hbit (the 

Re: [Lsr] Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

[Acee Lindem (acee)]

Hi Stephane,

From: Stephane Litkowski 
Date: Wednesday, November 28, 2018 at 7:04 AM
To: Acee Lindem , "lsr@ietf.org" , 
"draft-ietf-ospf-y...@ietf.org" 
Subject: RE: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

Hi Acee,

For the default values, some examples where I was expecting defaults: 
hello-interval, dead-interval, retransmit-interval, transmit-delay, passive, 
priority, cost…

There are no normative values for the interface timers – just suggested 
defaults in an RFC2328 appendix. The defaults can depend on the interface type 
and the deployment (much like the SPF delay timers). For cost, some 
implementations use 1 as the default (i.e., a hop count) and others default to 
making the cost inversely proportional to the link speed. I’m hesitant to 
define normative defaults. Are the timer defaults normative in the ISO IS-IS 
specification?

Another comment, in the last version of the IS-IS model, I have catched up all 
the existing IS-IS extensions in the LSDB description (all that have an IANA 
code point registered). What’s your plan for OSPF ?
This falls back the point that we have discussed by email on how we extend the 
base model with new extensions. One way would be to have the base model to 
catch up all the existing RFCs (that have implementations), and the on going 
drafts should have their own extension YANG model.

We have separate drafts now for OSPF SR and OSPFv3 extend LSAs. I think we 
should use what we have a baseline – least we never get done. We could update 
the RI LSA with some additional from RFCs that have been published. Let me 
discuss with the authors.

Thanks,
Acee

Brgds,

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Tuesday, November 27, 2018 23:53
To: LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org; draft-ietf-ospf-y...@ietf.org
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

Hey Stephane,
Thanks for the great review – I’ve incorporated most of your comments in the 
-18 version (just posted). See some inlines.

From: Stephane Litkowski 
Date: Wednesday, November 21, 2018 at 5:34 AM
To: "lsr@ietf.org" , "draft-ietf-ospf-y...@ietf.org" 

Subject: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Resent-From: 
Resent-To: Derek Yeung , Yingzhen Qu 
, Jeffrey Zhang , 
, Acee Lindem 
Resent-Date: Wednesday, November 21, 2018 at 5:34 AM

Hi,

Here are some comments I have on the model:

• The model should use the LSR WG as point of contact and no more the 
OSPF WG

• In the feature multi-topology: s/-Topolgy/-Topology

• In the packet-type typedef: 
s/database-descripton/database-description.

• In the container lsa-log description: s/conatiner/container

• OSPF model has no keychain feature, while ISIS has one. We need to 
agree on a common way to go.

I went ahead and added a feature to OSPF. It seems we have done this for other 
options outside the base RFCs.


• In the container link-tlvs, the link-type is an uint8 , wouldn’t it 
be better to use an enum to get a description of what is the link type ?

• Need to expand “af” to ”address-family” everywhere in the model 
(comments received from Yang doctor in the ISIS model review => ISIS has done 
this expansion).
I did this but am not so sure this is an improvement 


• Ietf-spf-delay timers use uint16 while ISIS uses 
timer-value-milliseconds

• The grouping instance-config has a “uses 
instance-fast-reroute-state”. It would be better to put it in the 
instance-state container.

• The model uses the “ospf-protocol” identity while IS-IS uses just 
“isis”. We need to find a common way to define the protocol identity name. RIP 
yang model uses just “rip”, so I suppose OSPF has to align.

• In the feature “fast-reroute” reference: s/Rereoute/Reroute/

• The description of the identity “ospf-lsa-type” is strange: “Base 
identity for OSPFv3 and OSPFv3 Link State Advertisements”. Do you mean just : 
“Base identity for OSPFv3 Link State Advertisements”
This should be “OSPFv2 and OSPFv3 …” I have updated in -18.


• It seems that you are using a typedef uint24 for the metric. In IS-IS 
there is  a metric typedef for this purpose.

•  In the if-state-type, the value 6 is referred as “bdr” while the RFC 
talks about “backup”. “bdr” works for sure, we just need to agree if we align 
on RFC naming or common usage naming.

• In the nbr-state-type, why using “ex-start” instead of “exstart”, 
again the RFC does not use the “-“.

• In the packet-type: s/Acknowlegement/Acknowledgement/

• In the ospfv2-router-link, the type is uint8, would be better to have 
an enum. Note that this appears multiple times in the model.

• In the leaf-list attached-router “line 1376”, why using dotted-quad 
instead of ip-address type ?
These are router-ids which are not necessarily IP addresses.


• In the grouping area-stat, there are 

[Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06

[Alvaro Retana]

Dear authors:

I just finished reading this document.  Even though it is relatively short,
I have significant concerns and I think it needs more work.  Please take a
look at the detailed comments in-line below -- I'm highlighting some of the
issues here.

(1) What is the Update to rfc2328?  Please be specific in both the Abstract
and the Introduction to indicate how rfc2328 is Updated.  Also, see my
question about rfc6987 in §6.

(2) Operational/Deployment Considerations.  There are several places
(specially in §3) where the specification offers a choice (e.g. by using
MAY).  Some of those choices would be better informed if there was a
discussion of the considerations behind them.  Please take a look at
rfc5706 (specially §2).  Either a discussion close to where the behavior is
specified or a separate section is ok.  Please also keep migration in mind
(see comments in §5).

(3) Both the IANA and Security Considerations sections need more details.


I will wait for them to be addressed before starting the IETF Last Call.

Thanks!

Alvaro.


[The line numbers come from idnits.]


11H-bit Support for OSPFv2
12 draft-ietf-ospf-ospfv2-hbit-06

[nit] Please make the title more descriptive.  "non-transit router", "host
mode", etc. come to mind.


14 Abstract

16   OSPFv3 defines an option bit for router-LSAs known as the R-bit in
17   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
18   OSPF topology flooding, however it will not be used as a transit
19   router.  In such cases, other routers in the OSPFv3 routing domain
20   only install routes to allow local traffic delivery.  This document
21   defines the H-bit functionality to prevent other OSPFv2 routers from
22   using the router for transit traffic in OSPFv2 routing domains as
23   described in RFC 2328.  This document updates RFC 2328.

[minor] Describing the functionality in terms of OSPFv2 would have been
nice.  IOW, there's no need (in the Abstract) to force the reader to go
figure out what OSPFv3 already did to decide if it's worth reading this
document or not.

[major] What is the Update to rfc2328?  Please be specific, both here and
in the Introduction: don't just mention the section updated, but (more
important) what is the update about.  "This document updates rfc2328 by
assigning a bit...changing the SPF process...creating a registry..."
 All/none/something else?

Note that the answer to "what is the update?" doesn't have to be all.  I
think that the registry creation is a must.  But Updating because of the
SPF changes means that you expect an rfc2328 implementation to consider the
H-bit when running SPF.  I think you really mean that implementations of
this document (i.e. not all rfc2328 implementations) have to use the
modified SPF.  That is my guess...please consider the answer carefully.



42 Copyright Notice

44   Copyright (c) 2018 IETF Trust and the persons identified as the
45   document authors.  All rights reserved.

47   This document is subject to BCP 78 and the IETF Trust's Legal
48   Provisions Relating to IETF Documents
49   (https://trustee.ietf.org/license-info) in effect on the date of
50   publication of this document.  Please review these documents
51   carefully, as they describe your rights and restrictions with respect
52   to this document.  Code Components extracted from this document must
53   include Simplified BSD License text as described in Section 4.e of
54   the Trust Legal Provisions and are provided without warranty as
55   described in the Simplified BSD License.

57   This document may contain material from IETF Documents or IETF
58   Contributions published or made publicly available before November
59   10, 2008.  The person(s) controlling the copyright in some of this
60   material may not have granted the IETF Trust the right to allow
61   modifications of such material outside the IETF Standards Process.
62   Without obtaining an adequate license from the person(s) controlling
63   the copyright in such materials, this document may not be modified
64   outside the IETF Standards Process, and derivative works of it may
65   not be created outside the IETF Standards Process, except to format
66   it for publication as an RFC or to translate it into languages other
67   than English.

[major] As far as I can tell, the first version of
draft-keyupate-ospf-ospfv2-hbit (the predecessor of this document) was
published in 2015.  So the copyright text above doesn't apply.  Are we
missing other predecessors?

If not, then this issue should be easy to fix.  In at least the XML editor
that I use, there's an option to indicate pre-RFC5378 work, or not.  In
this case it seems like it should be No.



85 1.  Introduction

[minor] Same comment as for the Abstract: describing the functionality in
terms of OSPFv2 would have been nicer.  You can still make the reference to
the R-bit at the end, if you really want to.

87   OSPFv3 [RFC5340] 

Re: [Lsr] Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

[stephane.litkowski]

Hi Acee,

For the default values, some examples where I was expecting defaults: 
hello-interval, dead-interval, retransmit-interval, transmit-delay, passive, 
priority, cost…

Another comment, in the last version of the IS-IS model, I have catched up all 
the existing IS-IS extensions in the LSDB description (all that have an IANA 
code point registered). What’s your plan for OSPF ?
This falls back the point that we have discussed by email on how we extend the 
base model with new extensions. One way would be to have the base model to 
catch up all the existing RFCs (that have implementations), and the on going 
drafts should have their own extension YANG model.

Brgds,

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Tuesday, November 27, 2018 23:53
To: LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org; draft-ietf-ospf-y...@ietf.org
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

Hey Stephane,
Thanks for the great review – I’ve incorporated most of your comments in the 
-18 version (just posted). See some inlines.

From: Stephane Litkowski 
Date: Wednesday, November 21, 2018 at 5:34 AM
To: "lsr@ietf.org" , "draft-ietf-ospf-y...@ietf.org" 

Subject: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Resent-From: 
Resent-To: Derek Yeung , Yingzhen Qu 
, Jeffrey Zhang , 
, Acee Lindem 
Resent-Date: Wednesday, November 21, 2018 at 5:34 AM

Hi,

Here are some comments I have on the model:

• The model should use the LSR WG as point of contact and no more the 
OSPF WG

• In the feature multi-topology: s/-Topolgy/-Topology

• In the packet-type typedef: 
s/database-descripton/database-description.

• In the container lsa-log description: s/conatiner/container

• OSPF model has no keychain feature, while ISIS has one. We need to 
agree on a common way to go.

I went ahead and added a feature to OSPF. It seems we have done this for other 
options outside the base RFCs.


• In the container link-tlvs, the link-type is an uint8 , wouldn’t it 
be better to use an enum to get a description of what is the link type ?

• Need to expand “af” to ”address-family” everywhere in the model 
(comments received from Yang doctor in the ISIS model review => ISIS has done 
this expansion).
I did this but am not so sure this is an improvement 


• Ietf-spf-delay timers use uint16 while ISIS uses 
timer-value-milliseconds

• The grouping instance-config has a “uses 
instance-fast-reroute-state”. It would be better to put it in the 
instance-state container.

• The model uses the “ospf-protocol” identity while IS-IS uses just 
“isis”. We need to find a common way to define the protocol identity name. RIP 
yang model uses just “rip”, so I suppose OSPF has to align.

• In the feature “fast-reroute” reference: s/Rereoute/Reroute/

• The description of the identity “ospf-lsa-type” is strange: “Base 
identity for OSPFv3 and OSPFv3 Link State Advertisements”. Do you mean just : 
“Base identity for OSPFv3 Link State Advertisements”
This should be “OSPFv2 and OSPFv3 …” I have updated in -18.


• It seems that you are using a typedef uint24 for the metric. In IS-IS 
there is  a metric typedef for this purpose.

•  In the if-state-type, the value 6 is referred as “bdr” while the RFC 
talks about “backup”. “bdr” works for sure, we just need to agree if we align 
on RFC naming or common usage naming.

• In the nbr-state-type, why using “ex-start” instead of “exstart”, 
again the RFC does not use the “-“.

• In the packet-type: s/Acknowlegement/Acknowledgement/

• In the ospfv2-router-link, the type is uint8, would be better to have 
an enum. Note that this appears multiple times in the model.

• In the leaf-list attached-router “line 1376”, why using dotted-quad 
instead of ip-address type ?
These are router-ids which are not necessarily IP addresses.


• In the grouping area-stat, there are checksum sums that are using 
int32 type while checksums are using uint32 or some other checksum sums (like 
in interface-stat) also use uint32. Need to be consistent here.

• In the grouping interface-physical-link-config, why do you say that 
it applies to physical interfaces ? Can’t you run OSPF on VLANs ?
By physical, I mean non-virtual. RFC 2328 uses this terminology. I did not 
change.


• Please set default values as much as you can (for instance in 
interface-common-config or interface-physical-link-config or interface-config…)
I’m hesitant to do this since these defaults are non-normative in the RFCs. Can 
you give an example? I think it is obvious that the absence of a feature means 
it is not configured.


• Why do you have interface-physical-link-config and interface-config, 
what difference do you make between the two ? My point is why there is still so 
much containers/leaves in the interface-config and why couldn’t we put them