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

[Les Ginsberg (ginsberg)]

Alvaro –

Comments inline.


From: Alvaro Retana 
Sent: Wednesday, November 28, 2018 2:38 PM
To: draft-ietf-lsr-isis-rfc7810...@ietf.org
Cc: Ketan Talaulikar (ketant) ; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: AD Review of draft-ietf-lsr-isis-rfc7810bis-02

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).

[Les:] Given that it is customary to list the editors first, I find it awkward 
to do this.

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

[Les:] I find this request a bit odd.
RFC7810 would certainly seem to be a normative reference as 99% of the text in 
the bis version is taken verbatim from RFC 7810.
RFC7471 is referenced only in the Appendix, but still – it is the consistency 
in language between the two documents which is one of the motivations for 
changes. This seems pretty essential to me.
???

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

[Les:] V3 of this draft has been published addressing this point.
If you agree with my comments above there is then no need for any additional 
changes.

   Les

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]

[Les Ginsberg (ginsberg)]

https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03 has been 
published. This addresses the inconsistency with RFC7471.

   Les


From: Les Ginsberg (ginsberg)
Sent: Wednesday, November 28, 2018 2:46 PM
To: Alvaro Retana ; 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]

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 mailto:aretana.i...@gmail.com>>
Sent: Wednesday, November 28, 2018 2:35 PM
To: John Scudder mailto:j...@juniper.net>>; 
draft-ietf-lsr-isis-rfc7810...@ietf.org
Cc: Hares Susan mailto:sha...@ndzh.com>>; 
idr-cha...@ietf.org; 
draft-ietf-idr-te-pm-...@ietf.org; 
idr@ietf. org mailto:i...@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 

[Lsr] I-D Action: draft-ietf-lsr-isis-rfc7810bis-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : IS-IS Traffic Engineering (TE) Metric Extensions
Authors : Les Ginsberg
  Stefano Previdi
  Spencer Giacolone
  Dave Ward
  John Drake
  Qin Wu
Filename: draft-ietf-lsr-isis-rfc7810bis-03.txt
Pages   : 19
Date: 2018-11-29

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc7810bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-rfc7810bis-03


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/

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

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

[stephane.litkowski]

Hi Acee,

In IS-IS some of the defaults we are using a coming from the ISO spec and some 
from vendor implementations (common used values). At the beginning we had no 
default in IS-IS, and during a review, there was a request to add defaults. I 
cannot remember who did this request.


From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, November 28, 2018 18:09
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

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.

•