Re: [Lsr] draft-ietf-isis-mpls-elc-07

[stephane.litkowski]

Hi Uma,

There was a discussion on this topic. I think this was agreed during Chicago's 
IETF if I remember correctly.
The outcome of the discussion was that if an implementation is able to read N 
labels, this does not mean that it is actually able to hash based on these N 
labels. So we needed something which combines the ability of reading + doing an 
action. That's why the ERLD has been defined instead of the base RLD which was 
foreseen at first stages of the draft.
This implies that there is a possibility to create additional RLDs that may 
have other applications than entropy.

Brgds,

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Uma Chunduri
Sent: Wednesday, August 28, 2019 20:38
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc-07

Can anybody tell what was the conclusion (if any) in previous discussions in 
various WGs on why the readable label depth in an LSR has to be entropy label 
specific ?

IOW can we just modify this as "readable label depth" as opposed to "entropy 
readable label depth" ?
This would allow any other special purpose label inserted in the stack and 
would be at par with current MSD type "Base MPLS Imposition MSD" ( 
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml ).


--
Uma C.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08 (Updated Subject)

[stephane.litkowski]

I’m not aware of any IPR

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, August 30, 2019 21:10
To: draft-ietf-ospf-mpls-...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "Signaling Entropy Label Capability and Entropy Readable 
Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08 (Updated Subject)



From: Acee Lindem 
Date: Friday, August 30, 2019 at 3:06 PM
To: "draft-ietf-ospf-mpls-...@ietf.org" 
Cc: "lsr@ietf.org" 
Subject: "Signaling Entropy Label Capability and Entropy Readable Label-stack 
Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Authors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-08?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

[stephane.litkowski]

I’m not aware of any IPR

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, August 30, 2019 21:11
To: draft-ietf-isis-mpls-...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "Signaling Entropy Label Capability and Entropy Readable 
Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Authors,

Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-07?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)

[stephane.litkowski]

I'm not aware of any IPR related to this document.

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org] 
Sent: Monday, July 29, 2019 19:22
To: lsr@ietf.org
Cc: Christian Hopps; lsr-cha...@ietf.org; lsr-...@ietf.org; 
draft-ietf-isis-yang-isis-...@ietf.org
Subject: WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)

Hi Folks,


As mentioned in the meeting in Montreal, due to mixup (IPR call but no WGLC) 
the IS-IS yang module was submitted to the IESG prior to a WGLC being done. We 
are belated doing a WGLC on this document now. Please voice any objections to 
the continued progression of this document. Prior to objecting though please do 
review any comments received during IESG reviews.

https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/

The WGLC will complete in 2 weeks on Aug 12th.

Authors (Stephane, Derek and Jeffery),

Please indicate if you are aware of any IPR related to this document in a reply 
to the mailing list (already received from Acee and Ladislav).


Thanks,
Chris & Acee.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] Dynamic flow control for flooding

[stephane.litkowski]

Les,

Can’t we use from a transmitter point of view, the lack of ACKs from the 
receiver as a signal that the transmitter should slow down ?
I agree that depending on the exact bottleneck/issue, the IS-IS stack of the 
receiver may not be aware that something bad is happening and can’t provide 
feedback to the transmitter. However if the transmitter sees that the receiver 
is acking slowly or quickly, wouldn’t it be able to adjust its flooding speed. 
Can we have a receiver intentionally postponing a PSNP to aggregate multiple 
ACKs in a single message ?

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, July 24, 2019 14:48
To: tony...@tony.li
Cc: LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org
Subject: RE: [Lsr] Dynamic flow control for flooding

More inline…

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Tuesday, July 23, 2019 10:56 PM
To: Les Ginsberg (ginsberg) 
Cc: stephane.litkow...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding


Les,

There is something to be said for simply “flooding fast” and not worrying about 
flow control at all (regardless of whether TX or RX mechanisms would be used).


The only thing I would say to that is: really bad idea.

[Les:] I have to watch my words more closely. 
I am not arguing for this – but I do think that “most of the time” this 
strategy would actually be optimal.
We are discussing the extreme cases – as we should – where we have a large # of 
LSPs to flood. But let’s not lose sight of the fact that the simple approach 
works most of the time. For the times when the simple approach doesn’t work 
well, I am then arguing we should not overcomplicate the solution – 
particularly because the strategies we might use don’t help convergence.

If you supersaturate the receiver, you waste transmitter in the transmission, 
you swamp the receiver causing packet loss, you potentially trigger the loss of 
IIH’s, you risk causing a cascade failure, and until we come up with a better 
retransmission mechanism, you probably actually delay network convergence, as 
nothing is going to happen until you’ve completed retransmissions.
[Les:] Prioritization of hellos over LSPs/SNPs is a longstanding best practice 
(both on Tx and Rx) and this must not change. No one is advocating that – 
certainly not me.

The way to maximize goodput is NOT to transmit blindly.


[Les:] Not arguing for blindness, but I am arguing for simplicity.

But most important to me is to recognize that flow control (however done) is 
not fixing anything – nor making the flooding work better. The network is 
compromised and flow control won’t fix it.


 The network is not compromised.

[Les:] If the SLA the customer expects is convergence in less than N, then a 
slow link jeopardizes our ability to achieve that.

If you accept that, then it makes sense to look for the simplest way to do flow 
control and that is decidedly not from the RX side. (I expect Tony Li to 
disagree with that – but I have already outlined why it is more complex to do 
it from the Rx side.)



Flow control cannot be done without involvement of the RX side.  That’s why 
it’s called flow _control_.  The only thing that can be done purely from the TX 
side is a unilateral (and pessimal) transmit rate cap that will have to allow 
for the worst case CPU in the worst case situation (e.g., BGP impacting the 
CPU).

Flow control is the creation of a control loop and that requires feedback from 
the receiver.  This is true in every form of true flow control: XON/XOFF, 
RTS/CTS, sliding window protocols, credit based fabric mechanisms, etc.

I’ll go so far as to quote Wikipedia:

"In data communications, 
flow control is the process of managing the rate of data transmission between 
two nodes to prevent a fast sender from overwhelming a slow receiver. It 
provides a mechanism for the receiver to control the transmission speed, so 
that the receiving node is not overwhelmed with data from transmitting node.”

[Les:] I will not argue about the definition.
In this specific case, there are difficulties in controlling the flooding rate 
based on advertisements from the RX side. The difficulties are outlined in my 
slides and largely have to do with the difficulties/costs of dynamically 
calculating what number to advertise. (A static advertisement is also difficult 
to calculate w/o being overly conservative.)

If you disagree please take things bullet-by-bullet:


  *   LSP input queue implementations are typically interface independent FIFOs
  *   Overloaded Receiver does not know which senders are disproportionately 
causing the overflow
  *   LSPs may be dropped at lower layers – IS-IS receiver may be unaware that 
the overload condition exists
  *   Updating hellos dynamically to alter flooding transmission rate is an OOB 
signaling mechanism consuming  resources at a time when routers are the most 
busy
  *   Consistent flooding rates 

Re: [Lsr] Dynamic flow control for flooding

[stephane.litkowski]

Hi Les,

I agree that flooding is a global thing and not a local mechanism if we 
consider that the ultimate goal is to get the LSDB in-sync as fast as we can on 
all the nodes.

I just want to highlight three things:

-  Link delay (due to transmission link distance) is already affecting 
the flooding speed (especially when we need to cross some links which have 
100msec of RTD), so the flooding speed is already not equal on each link

-  I put this one in parenthesis as it may be controversial ☺ (To 
converge a path after a topology change, we do not always require all the nodes 
to get the LSDB in-sync (I mean from a fwding point of view). That’s a tricky 
topic because it is highly depending on the network topology and in one hand 
flooding one or two hops away allows to converge the path, while in an other 
hand, it may create microloops with another network design. )

-  I’m really wondering how much difference we may have considering the 
different routers we have in a single area today. Even if we have some legacy 
routers still deployed, they are more powerful compared to the time the ISO 
spec was done. Are we expecting hundreds of msec difference or tens between 
last generation of routers deployed and the legacy one ? In addition, in our 
case, we try to create consistent design, which means that we are trying to 
avoid having legacy routers in transit between last generation of routers and 
we are pushing the legacy one at the edge or try to remove them. There may be 
some transient situation when it happens but that’s not a design goal. This is 
to say that I’m not hurted to get a very fast flooding value on my core and 
last generation edges while letting a more conservative value for legacy edges. 
And I’m not expecting to have so much differences between the two (at least not 
really more than the link delay that may already exists and impact flooding).

Another point is that I would be really glad to see how much the flooding time 
is impacting the convergence time in real networks taking into account that the 
FIB rewrite is usually the biggest contributor (unfortunately we don’t have 
really instrumentation today to measure flooding). I’m not telling that there 
is nothing to do, of course the default flooding time we had for years could be 
improved and I fully agree. I’m just always interested to have some potential 
gain measurement.

Flow control is required in any case, we can always find a case when the IS-IS 
process will not get enough CPU time because CPU is busy doing other stuffs and 
IS-IS can’t process the input PDUs (as an example).


Brgds,

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, July 23, 2019 16:30
To: Tony Li; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding

Tony –

Thanx for picking up the discussion.
Thanx also for doing the math to show that bandwidth is not a concern. I think 
most/all of us knew that – but it is good to put that small question behind us.

I also think we all agree on the goal - which is to flood significantly faster 
than many implementations do today to handle deployments like the case you 
mention below.

Beyond this point, I have a different perspective.

As network-wide convergence depends upon fast propagation of LSP changes – 
which in turn requires consistent flooding rates on all interfaces enabled for 
flooding – a properly provisioned network MUST be able to sustain a consistent 
flooding rate or the operation of the network will suffer. We therefore need to 
view flow control issues as indicative of a problem.

It is a mistake to equate LSP flooding with a set of independent P2P 
“connections” – each of which can operate at a rate independent of the other.

If we can agree on this, then I believe we will have placed the flow control 
problem in its proper perspective – in which case it will become easier to 
agree on the best way to implement flow control.

   Les



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Tuesday, July 23, 2019 6:34 AM
To: lsr@ietf.org
Subject: [Lsr] Dynamic flow control for flooding


Hi all,

I’d like to continue the discussion that we left off with last night.

The use case that I posited was a situation where we had 1000 LSPs to flood. 
This is an interesting case that can happen if there was a large network that 
partitioned and has now healed.  All LSPs from the other side of the partition 
are going to need to be updated.

Let’s further suppose that the LSPs have an average size of 1KB.  Thus, the 
entire transfer is around 1MB.

Suppose that we’re doing this on a 400Gb/s link. If we were to transmit the 
whole batch of LSPs at once, it takes a whopping 20us.  Not milliseconds, 
microseconds.  2x10^-5s.  Clearly, we are not going to be rate limited by 
bandwidth.

Note that 20us is an unreasonable lower bound: we cannot reasonably expect a 
node to absorb 1k PDUs back to 

Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

[stephane.litkowski]

Hi Alvaro,

Thanks for your comments. We are working on updating the document accordingly.
Please find some replies inline that may require more discussion.
I have stripped the comments that will be fixed in the next revision.

Brgds,


From: Alvaro Retana [mailto:aretana.i...@gmail.com]
Sent: Tuesday, June 04, 2019 23:34
To: draft-ietf-isis-yang-isis-...@ietf.org
Cc: Yingzhen Qu; lsr-cha...@ietf.org; lsr@ietf.org
Subject: AD Review of draft-ietf-isis-yang-isis-cfg-35

Dear authors:

Thank you for the work on this document!!

I just (finally!) finished reading this model.  I have several comments in-line 
below, including some that I consider major -- I would like those to be 
addressed before moving the document forward.

Thanks!

Alvaro.


[Line numbers come from id-nits.]


474 Some parameters like "overload bit" and "route preference" are not
475 modeled to support a per level configuration.  If an implementation
476 supports per level configuration for such parameter, this
477 implementation SHOULD augment the current model by adding both
478 level-1 and level-2 containers and SHOULD reuse existing
479 configuration groupings.

[major] "...SHOULD augment the current model by adding both level-1 and level-2 
containers"  What other way would that be done?  I think that Normative 
language is not needed in this case.
[SLI] Using YANG there are multiple ways to do things. People may create new 
containers, use different namings… and we want to keep the modeling consistency 
even in the future augmentations.




548  +--rw tag* uint32 {prefix-tag}?
549  +--rw tag64*   uint64 {prefix-tag64}?
550  +--rw node-flag?   boolean {node-flag}?
551  +--rw hello-authentication
552  |  +--rw (authentication-type)?
553  |  |  +--:(key-chain) {key-chain}?
554  |  |  |  +--rw key-chain?
555  |  |  |  key-chain:key-chain-ref
556  |  |  +--:(password)
557  |  | +--rw key?string
558  |  | +--rw crypto-algorithm?   identityref
559  |  +--rw level-1
560  |  |  +--rw (authentication-type)?
561  |  | +--:(key-chain) {key-chain}?
562  |  | |  +--rw key-chain?
563  |  | |key-chain:key-chain-ref
564  |  | +--:(password)
565  |  |+--rw key?string
566  |  |+--rw crypto-algorithm?   identityref
567  |  +--rw level-2
568  | +--rw (authentication-type)?
569  |+--:(key-chain) {key-chain}?
570  ||  +--rw key-chain?
571  ||  key-chain:key-chain-ref
572  |+--:(password)
573  |   +--rw key?string
574  |   +--rw crypto-algorithm?   identityref
575  +--rw hello-interval
576  |  +--rw value? rt-types:timer-value-seconds16
577  |  +--rw level-1
578  |  |  +--rw value?   rt-types:timer-value-seconds16
579  |  +--rw level-2
580  | +--rw value?   rt-types:timer-value-seconds16

[minor] Some implementations support having a sub-second hello-interval...but 
with a timer in seconds that can't be done.
[SLI] We don’t think that it is a good idea. Sub-second timers were implemented 
at the time when BFD wasn’t available. BFD provides a better mechanism for fast 
detection and is supported in the model. BFD is widely deployed compared to 
sub-second timers which do not scale. If a vendor wants to add the support for 
sub-second hello, this can be done by augmentation but we don’t want to 
encourage this usage.

...
978sequence-number-skipped: This notification is sent when the 
system
979receives a PDU with its own system ID and different contents.  
The
980system has to reissue the LSP with a higher sequence number.

[nit] That's the last thing I would have guessed that this action would have 
been called...  Maybe it's just me...
[SLI] This is inherited from RFC


982authentication-type-failure: This notification is sent when the
983system receives a PDU with the wrong authentication type field.

985authentication-failure: This notification is sent when the system
986receives a PDU with the wrong authentication information.

[minor] Why do we need both of these?  Given that they both provide the same 
information (including the raw PDU), and that 

Re: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

[stephane.litkowski]

Support

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 12, 2019 14:05
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Subject: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv.

https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/

Please express your support or non-support.

Authors: Please indicate your knowledge of any IPR related to this work to the 
list as well.

Thanks,
Chris & Acee.



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

[stephane.litkowski]

Hi Xufeng,

Good catch, I think there is a mistake here, the expected behavior is the one 
described in the draft. We should not use a default value for the level-x 
leaves.
Will fix it in the next release as part of the AD review.

Brgds,

Stephane


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Xufeng Liu
Sent: Sunday, June 09, 2019 16:35
To: lsr@ietf.org; NETMOD WG
Subject: [Lsr] A question on the parameter overriding in 
draft-ietf-isis-yang-isis-cfg


In Section 2.3. and many other locations, the current IS-IS model applies the 
parameter overriding rule as below:

[Quote]:

2.3.  
Per-Level Parameters





   Some parameters allow a per level configuration.  In this case, the

   parameter is modeled as a container with three configuration

   locations:



   o  a top-level container: corresponds to level-1-2, so the

  configuration applies to both levels.



   o  a level-1 container: corresponds to level-1 specific parameters.



   o  a level-2 container: corresponds to level-2 specific parameters.



   +--rw priority

   |  +--rw value? uint8

   |  +--rw level-1

   |  |  +--rw value?   uint8

   |  +--rw level-2

   | +--rw value?   uint8



   Example:



   

   250

   

   100

   

   

   200

   

   



   An implementation SHOULD prefer a level specific parameter over a

   level-all parameter.  As example, if the priority is 100 for the

   level-1, 200 for the level-2 and 250 for the top-level configuration,

   the implementation should use 100 for the level-1 and 200 for the

   level-2.

[End of Quote]



In the model, all three value leaves above have a default statement “default 
64”, which brings up my question for the following example:



   

   250

   

   100

   

   



The user does not provide a configured value for level-2. According to Section 
7.6.1. of RFC7950, because the default value is in use, “the server MUST 
operationally behave as if the leaf was present in the data tree with the 
default value as its value”. This means the priority value for level-2 will be 
64 (the default value), so the value 250 can never take effect as intended in 
the above quoted Section 2.3.



Is my understanding correct?



Since this is a generic question, I am CC’ing NETMOD WG too.



Thanks,

- Xufeng



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] I-D Action: draft-ietf-isis-yang-isis-cfg-35.txt

[stephane.litkowski]

Hi Tom,

Thanks for your feedback.
Pls find some comments inline

Stephane

-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Thursday, June 06, 2019 18:59
To: LITKOWSKI Stephane OBS/OINIS
Cc: lsr@ietf.org
Subject: Re: I-D Action: draft-ietf-isis-yang-isis-cfg-35.txt

Stephane

The YANG module has RFC5307 in a description clause but I do not see
this in the References of the I-D

[SLI] That's a mistake, I will fix it


I commented before on the lack of  a conditional when on
 augment "/if:interfaces/if:interface"
so every interface will get this object; is that intended?

[SLI] It looks good to me, if a device supports the ISIS model, all the 
interfaces should get the clns-mtu config statement.

In the example, is the system-id one reserved for documentation?
[SLI] No, but I'm personally not aware of system IDs reserved for documentation 
as we could have for IP addresses. If someone from the WG knows about it, I 
will be happy to change it.



Tom Petch

- Original Message -
From: 
To: 
Cc: 
Sent: Friday, March 08, 2019 3:37 AM
Subject: I-D Action: draft-ietf-isis-yang-isis-cfg-35.txt


>
> 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   : YANG Data Model for IS-IS Protocol
> Authors : Stephane Litkowski
>   Derek Yeung
>   Acee Lindem
>   Jeffrey Zhang
>   Ladislav Lhotka
> Filename: draft-ietf-isis-yang-isis-cfg-35.txt
> Pages   : 111
> Date: 2019-03-07
>
> Abstract:
>This document defines a YANG data model that can be used to
configure
>and manage IS-IS protocol on network elements.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-yang-isis-cfg-35
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-yang-isis-cfg-35
>
>
> 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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] When to augment LSR base YANG modules...

[stephane.litkowski]

Hi,

On one hand, I'm a bit worried about having too many tiny modules (finding the 
right module name to get the right feature, managing prefixes...). The good 
thing I see is that we could mandate in each LSR draft the YANG management part 
so both are published at the same time. While YANG is easy to write, it could 
still scare pure IGP guys that are focused on protocol encodings -> this 
implies that people may need to rely on people with YANG skills to write the 
management section.

On the other hand, we have few (or even no) experience today on managing 
modules revisions, do we also foresee some level of complexity ? The issue I 
see if we update the main YANG base module is that the timing may be different 
from the protocol encoding spec. Also, are we ready to publish a revision for 
each tiny feature ?(why not but who takes the pen ? Speaking as editor of ISIS 
yang module, I'm not really ready to have the pen to modify it for the rest of 
my life ;)

I think the main requirement (speaking as an operator) is to get the YANG part 
(ops+cfg) standardized at the same time. 


Brgds,


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Friday, March 29, 2019 09:17
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] When to augment LSR base YANG modules...


The base YANG modules for IS-IS and OSPF both include operational state to 
describe TLV data. During the discussion about OSPFv3's version of this data, I 
brought up the issue of when and how the base modules should be augmented to 
add new TLV types to the model, suggesting it be done inline and with the RFC 
that adds the new feature/functionality to the protocol.

I'll go farther here and say this should apply to all the YANG required for 
management of the new feature, and it should all be added inline with the 
feature (i.e., in the same draft). In other words new features/functionality 
should include the YANG augment required to manage said features/functionality.

This has been suggested/tried previously with SNMP with varying (low) levels of 
success. The difference here is 1) YANG additions (a new module perhaps just 
augmenting the base) is easy, whereas SNMP wasn't. Additionally, operators 
weren't using SNMP to fully manage functionality (e.g., not doing 
configuration) so a requirement for extra work was harder to justify. Operators 
*do* want to fully manage their networks/servers with YANG though.

The argument against this during the meeting was that it would create many 
small modules. I don't find this compelling (i.e., "so"? :)

Assume I'm an operator -- the actual consumer of this management stuff:

  - If I'm going to use this new feature X, I need to be able to manage it. So 
I need it YANG for it. Not only do I need any new TLV data in the operational 
state, but I need the configuration and any other operational state right along 
with it. Otherwise each vendor has to add new YANG to their vendor modules, or 
the feature is useless to me. I can't use something if I can't turn it on.

  - I don't care about having many smaller modules that augment the base module 
-- at all. Quite the opposite actually, when new functionality is accompanied 
by it's own module it provides me a simple way to see if that functionality is 
present as the module will be present in the YANG capabilities announced by the 
device.

I'd be interested in hearing reasons we (as a WG) shouldn't just expect a YANG 
module (even if it's small) to be included with drafts that add new 
functionality.

Thanks,
Chris.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] IPR Call for "YANG Data Model for IS-IS protocol" - draft-ietf-isis-yang-isis-cfg-29

[stephane.litkowski]

I’m not aware of any IPR

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Saturday, January 12, 2019 23:21
To: draft-ietf-isis-yang-isis-...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call for "YANG Data Model for IS-IS protocol" - 
draft-ietf-isis-yang-isis-cfg-29

Authors,

Are you aware of any IPR that applies to draft-ietf-isis-yang-isis-cfg?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are currently no IPR disclosures.

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing list. The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29

[stephane.litkowski]

Ok, so if we are silent about "must support at least", I think the only thing 
to do is to have 'type string "1.."' to avoid empty string as I don't see any 
requirement to have a minimum of x characters.


-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Wednesday, January 09, 2019 15:27
To: LITKOWSKI Stephane OBS/OINIS
Cc: tom petch; Ebben Aries; yang-doct...@ietf.org; 
draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of 
draft-ietf-isis-yang-is-is-cfg-29

Implementations must be robust and be able to deal with rogue input, a
length restriction in the data model does not help solving that problem.

Perhaps an example helps for the other question:

leaf example {
  type string "3..";
  description
"implementation must support a length of at least 42 characters"
}

Valid input can be any string which has at least three characters and
implementations are expected to handle at least strings up to 42
characters. An other alternative is to be silent about any
expectations. A third option is to let server implementors document
via deviations any length restrictions they may impose in their
implementation.

My preference is actually to be silent about "must support at least"
constrained unless there is a clear technical reason for a specific
number.

/js

On Wed, Jan 09, 2019 at 01:27:05PM +, stephane.litkow...@orange.com wrote:
> Hi Juergen,
> 
> There is something that I'm missing (sorry for that). How defining a minimum 
> length helps to deal with rogue input ? I see a rogue input more being a too 
> long string. Too short can happen if a specific leaf really requires a 
> minimum length string, but I don't think that we have such a case.
> In addition, when your talk about minimum length in your email below, do I 
> need to understand it as  "minimum length to be supported by the 
> implementation" ? (you said before: "'implementations should at least handle 
> a length of x characters'"). This means that the user can input a string of 
> any size between 0 and this minimum length to be supported. Or is it really a 
> minimum length so the user cannot input something shorter than this value ?
> 
> Brgds,
> 
> 
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> Sent: Wednesday, January 09, 2019 13:10
> To: tom petch
> Cc: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org; 
> draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of 
> draft-ietf-isis-yang-is-is-cfg-29
> 
> Hi,
> 
> just to clarify: My position is that implementations have to be able
> to deal with rogue input no matter whether there is a length
> restriction defined in a data model or not. If people argue for length
> restrictions, then this should be done for interoperability reasons.
> And for this you may want to define a minimum length that must be
> supported instead of a maximum length that defines a hard upper
> boundary (and the only place to define such a minimum length and
> implementations must support so far is in the description statement).
> 
> /js
> 
> On Wed, Jan 09, 2019 at 11:37:45AM +, tom petch wrote:
> > Stephane
> > 
> > Thanks for persisting.
> > 
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
> > lively discussion in other WG.  Even before that, whenever I see a
> > string, I think is there an implicit length restriction and if not,
> > should there be an explicit one which, as Juergen suggested, could be in
> > the description clause.  My experience is that those working with
> > networks think about size, about length; those coming from applications
> > tend to think 'What is a few terabytes between friends?' and are unaware
> > that sizes that may be commonplace in servers and associated storage can
> > create difficulties over a network.  Whatever, I leave this one up to
> > you.
> > 
> > On references, I would like a change; you say this information is in the
> > base ISO spec.  Well, yes, to me that means that it should be a
> > Normative Reference.  I could not understand the description of e.g.
> > 'i/e' and needed to look it up but seemingly cannot do so with the
> > listed references of the I-D.  Note that RFC such as RFC5305 and RFC6119
> > do reference International Standard 10589 and I think that this one
> > should too, perhaps in s.2.7 and s.5.
> > 
> > Tom Petch
> > 
> > - Original Message -
> > From: 
> > Sent: Wednesday, January 09, 2019 9:18 AM
> > 
> > Hi Tom,
> > 
> > Please find inline answers.
> > 
> > 
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Tuesday, January 08, 2019 18:45
> > 
> > Ok. 

Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29

[stephane.litkowski]

Hi Juergen,

There is something that I'm missing (sorry for that). How defining a minimum 
length helps to deal with rogue input ? I see a rogue input more being a too 
long string. Too short can happen if a specific leaf really requires a minimum 
length string, but I don't think that we have such a case.
In addition, when your talk about minimum length in your email below, do I need 
to understand it as  "minimum length to be supported by the implementation" ? 
(you said before: "'implementations should at least handle a length of x 
characters'"). This means that the user can input a string of any size between 
0 and this minimum length to be supported. Or is it really a minimum length so 
the user cannot input something shorter than this value ?

Brgds,


-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Wednesday, January 09, 2019 13:10
To: tom petch
Cc: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org; 
draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of 
draft-ietf-isis-yang-is-is-cfg-29

Hi,

just to clarify: My position is that implementations have to be able
to deal with rogue input no matter whether there is a length
restriction defined in a data model or not. If people argue for length
restrictions, then this should be done for interoperability reasons.
And for this you may want to define a minimum length that must be
supported instead of a maximum length that defines a hard upper
boundary (and the only place to define such a minimum length and
implementations must support so far is in the description statement).

/js

On Wed, Jan 09, 2019 at 11:37:45AM +, tom petch wrote:
> Stephane
> 
> Thanks for persisting.
> 
> On string lengths, I take your point about no user input to Operational
> State; there, my concern is more about giving guidance to implementors
> as to what they should cater for - as I said, this has been a topic of
> lively discussion in other WG.  Even before that, whenever I see a
> string, I think is there an implicit length restriction and if not,
> should there be an explicit one which, as Juergen suggested, could be in
> the description clause.  My experience is that those working with
> networks think about size, about length; those coming from applications
> tend to think 'What is a few terabytes between friends?' and are unaware
> that sizes that may be commonplace in servers and associated storage can
> create difficulties over a network.  Whatever, I leave this one up to
> you.
> 
> On references, I would like a change; you say this information is in the
> base ISO spec.  Well, yes, to me that means that it should be a
> Normative Reference.  I could not understand the description of e.g.
> 'i/e' and needed to look it up but seemingly cannot do so with the
> listed references of the I-D.  Note that RFC such as RFC5305 and RFC6119
> do reference International Standard 10589 and I think that this one
> should too, perhaps in s.2.7 and s.5.
> 
> Tom Petch
> 
> - Original Message -
> From: 
> Sent: Wednesday, January 09, 2019 9:18 AM
> 
> Hi Tom,
> 
> Please find inline answers.
> 
> 
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Tuesday, January 08, 2019 18:45
> 
> Ok.  Top-posting the ones that are not 'ok':
> 
> I said that I thought that LSP did not need expanding on first use and
> then checked the RFC Editor list to find that it is not one they regard
> as well-known and that LSR protocols use it differently to others, so I
> suggest expanding LSP on first use.
> 
> [SLI] Already done for the next version.
> 
> On lengths of text messages, perhaps I am too sensitive to buffer
> overrun attacks and the like and so want a maximum on many things (and
> then people attach a friendly, 20Mbyte photo to their e-mail at
> Christmas and
> wonder why their ESP rejects the message so I do not congratulate them
> on the latest addition to the family:-).  The IDR WG had a lively
> discussion about maximum message lengths in 2017 and that has also
> stayed in my mind.  I have seen the comments on this by Juergen and
> Lada; perhaps as Juergen intimates, something in the Description would
> help; and while the server may not be rogue, it may not have a perfect
> implementation.
> 
> [SLI] What I need to understand from your comment on string length
> enforcement is if it applies to operational state or just config states
> ? I do not see any issue of not enforcing the operational state as there
> is no input from the user there and so no attack vector, this is purely
> internal to the implementation. For config statements, it makes sense as
> there is an input from the user that can be anything.
> 
> 
> On the length of password, I saw a Security AD wanting clarification on
> this not too long ago so you may see this comment again from one such .
> Likewise, MD5 tends to be a red flag 

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29

[stephane.litkowski]

Hi Tom,

Regarding the length enforcement for operational state leaves that are using 
string, do we need to always do it as a best practice ? There are plenty of 
strings with no enforcement today like the "non-best-reason" that you have 
pointed.

Brgds,


-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Wednesday, January 02, 2019 12:17
To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Yangdoctors last call review of 
draft-ietf-isis-yang-is-is-cfg-29

Here are the rest of my comments on -29 with a slight tweak to the
subject line.  I would regard most of these (but not the first two) as
non-discussable, ie I won't complain if you disagree:-)

RFC1195 is in the YANG module but not the references of the I-D

RFC5029 is in the YANG module but not the references of the I-D

PSNPs, CSNPs
expand on first use - LSP I think ok

leaf best {   type boolean;
what is true and what false?  I can guess from the English semantics of
the name but would rather not guess.

leaf non-best-reason {  type string;
suggest a maximum length, perhaps 127 or 255 ( unless you expect
screenshots or packet traces to be attached).  As it stands, you could
validly receive
a length of 18446744073709551615.

You have a mixture of
System-id system-id System id System ID System Id system id system ID
suggest consistency; system-id wfm

You have a mixture of
lsp-id LSPID LSP ID
here, perhaps lsp-id for the names and LSP ID in the text

  case password {leaf key {   type string;
perhaps better with a minimum length

leaf i-e {  type boolean;
what is true and what false?  here I am reluctant even to guess

/"Authentication keyto/  "Authentication key to/

" the authentication key MUST NOT be presented in"
RFC2119 language means that RFC2119 boilerplate should be in the YANG
module (but without the [..] ie the reference must be plain text not an
anchor).


 It is recommended to use an MD5
   hash to present the authentication-key.";
Mmm I think that this may be a red flag to security AD or directorate as
being too vague as well as MD5 too weak; and I think this should be
explicitly called out in Security Considerations.

  list level-db {key level;leaf level {
A common convention is for a list of leaf thing to be named things i.e.
  list levels { key level;leaf level {

  rpc clear-adjacency {
  "Name of the IS-IS protocol instance whose IS-IS
   information is being queried.
queried or cleared?

Tom Petch


- Original Message -
From: "tom petch" 
Sent: Monday, December 31, 2018 6:21 PM
Subject: Re: [Lsr] Yangdoctors last call review of
draft-ietf-isis-yang-isis-cfg-24


> Stephane
>
> A new and different comment.
>
>   grouping neighbor-gmpls-extensions {
>
> has a text reference to RFC5307 which does not appear in the
references
> for the I-D.  However, before adding it, I would like to know why it
is
> a good reference for switching capabilities (which is part of this
> grouping).  I think that the reference for switching capabilities
should
> be RFC7074 (which this I-D does not currently reference and should
IMO).
>
> And that begs the  question, why is switching-capability an
unrestricted
> uint8 when only 12 values are valid and three are deprecated?
>
> So why not use
>
> draft-ietf-teas-yang-te-types?
>
> I have a number of additional comments on cfg-29 but this is the one
> that may take some discussion.
>
> Tom Petch
>
>
> - Original Message -
> From: 
>
> Hi Tom,
>
> Thanks for your comments. I will fix them asap.
> Regarding:
> " Line length is within the RFC limit but the effect is to spread many
> of the description clauses over multiple lines with indentation of 56
> characters, not user friendly e.g.
> description
> "List of max LSP
> bandwidths for different
>  priorities.";
> "
> What's your suggestion on this one ?
>
> Brgds,
>
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Tuesday, November 27, 2018 12:11
> To: Ebben Aries; yang-doct...@ietf.org
> Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org; Tarek
Saad
> (tsaad)
> Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-isis-cfg-24
>
> Some quirks in-25
>
> I see lots of YANG reference statements - good - but no mention of
them
> in the I-D references - not so good.  My list is
>
> 5130
> 5305
> 5306
> 5880
> 5881
> 6119
> 6232
> 7794
> 7810
> 7917
> 8405
>
> Also perhaps
> OLD
> reference "RFC  - YANG Data Model for Bidirectional
>Forwarding Detection (BFD).Please replace  with
>  published RFC
> number for 

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29

[stephane.litkowski]

Hi Tom,

Thanks for your comments.
I wish you an happy new year !

Please find inline comments.

Brgds,

-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Wednesday, January 02, 2019 12:17
To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Yangdoctors last call review of 
draft-ietf-isis-yang-is-is-cfg-29

Here are the rest of my comments on -29 with a slight tweak to the
subject line.  I would regard most of these (but not the first two) as
non-discussable, ie I won't complain if you disagree:-)

RFC1195 is in the YANG module but not the references of the I-D
[SLI] Will fix it

RFC5029 is in the YANG module but not the references of the I-D
[SLI] Will fix it

PSNPs, CSNPs
[SLI] Will fix it

expand on first use - LSP I think ok

leaf best {   type boolean;
what is true and what false?  I can guess from the English semantics of
the name but would rather not guess.
[SLI] Will fix it
To replace the current description which is : ""Indicates if the alternate is 
the preferred."", do you prefer: "Set to true when the alternate is preferred, 
set to false otherwise" ?


leaf non-best-reason {  type string;
suggest a maximum length, perhaps 127 or 255 ( unless you expect
screenshots or packet traces to be attached).  As it stands, you could
validly receive
a length of 18446744073709551615.
[SLI] Agree, will fix it

You have a mixture of
System-id system-id System id System ID System Id system id system ID
suggest consistency; system-id wfm
[SLI] Will fix it

You have a mixture of
lsp-id LSPID LSP ID
here, perhaps lsp-id for the names and LSP ID in the text
[SLI] Will fix it

  case password {leaf key {   type string;
perhaps better with a minimum length
[SLI] I agree that it could make sense but is it really something that we 
should impose ?


leaf i-e {  type boolean;
what is true and what false?  here I am reluctant even to guess
[SLI] This is coming from the standard, is it really worth repeating it ? Same 
for up/down bit.


/"Authentication keyto/  "Authentication key to/

" the authentication key MUST NOT be presented in"
RFC2119 language means that RFC2119 boilerplate should be in the YANG
module (but without the [..] ie the reference must be plain text not an
anchor).

[SLI] You are right, it is missing.


 It is recommended to use an MD5
   hash to present the authentication-key.";
Mmm I think that this may be a red flag to security AD or directorate as
being too vague as well as MD5 too weak; and I think this should be
explicitly called out in Security Considerations.

[SLI] I agree that there is a point to discuss here. The fact is that we must 
not retrieve passwords in clear text. Maybe it is something with a wider scope 
than IS-IS. How do the other models deal with passwords retrieved through "get" 
or "get-config" ?


  list level-db {key level;leaf level {
A common convention is for a list of leaf thing to be named things i.e.
  list levels { key level;leaf level {

[SLI] ack

  rpc clear-adjacency {
  "Name of the IS-IS protocol instance whose IS-IS
   information is being queried.
queried or cleared?
[SLI] "cleared"

Tom Petch


- Original Message -
From: "tom petch" 
Sent: Monday, December 31, 2018 6:21 PM
Subject: Re: [Lsr] Yangdoctors last call review of
draft-ietf-isis-yang-isis-cfg-24


> Stephane
>
> A new and different comment.
>
>   grouping neighbor-gmpls-extensions {
>
> has a text reference to RFC5307 which does not appear in the
references
> for the I-D.  However, before adding it, I would like to know why it
is
> a good reference for switching capabilities (which is part of this
> grouping).  I think that the reference for switching capabilities
should
> be RFC7074 (which this I-D does not currently reference and should
IMO).
>
> And that begs the  question, why is switching-capability an
unrestricted
> uint8 when only 12 values are valid and three are deprecated?
>
> So why not use
>
> draft-ietf-teas-yang-te-types?
>
> I have a number of additional comments on cfg-29 but this is the one
> that may take some discussion.
>
> Tom Petch
>
>
> - Original Message -
> From: 
>
> Hi Tom,
>
> Thanks for your comments. I will fix them asap.
> Regarding:
> " Line length is within the RFC limit but the effect is to spread many
> of the description clauses over multiple lines with indentation of 56
> characters, not user friendly e.g.
> description
> "List of max LSP
> bandwidths for different
>  priorities.";
> "
> What's your suggestion on this one ?
>
> Brgds,
>
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Tuesday, November 27, 2018 12:11
> 

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

[stephane.litkowski]

Acee and  co-authors,

The last version of the model has a compilation failed status in the YANG 
catalog.
https://yangcatalog.org/results/ietf-ospf@2018-11-27_ietf.html

Could you check what’s going on ?


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 10, 2018 10:16
To: Acee Lindem (acee); lsr@ietf.org; draft-ietf-ospf-y...@ietf.org
Subject: Re: [Lsr] Shepherd's review of ietf-ospf.yang and 
draft-ietf-ospf-yang-17

Hi Acee,

I’m fine with that.


From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, December 07, 2018 18:03
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,
I’ve added sample values or guidance to the descriptions of these parameters 
based on Appendix C in RFC 2328. I don’t think we should use these as defaults 
unless they are normative in the existing standards as implementations of the 
YANG model will have to guarantee these defaults or use deviations.
Thanks,
Acee

From: Stephane Litkowski 
Date: Thursday, November 29, 2018 at 5:44 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,

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” 

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

[stephane.litkowski]

Hi Acee,

I’m fine with that.


From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, December 07, 2018 18:03
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,
I’ve added sample values or guidance to the descriptions of these parameters 
based on Appendix C in RFC 2328. I don’t think we should use these as defaults 
unless they are normative in the existing standards as implementations of the 
YANG model will have to guarantee these defaults or use deviations.
Thanks,
Acee

From: Stephane Litkowski 
Date: Thursday, November 29, 2018 at 5:44 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,

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 

Re: [Lsr] draft-ietf-ospf-yang

[stephane.litkowski]

Hi Tom,

I think that having a different router-id configured per protocol is a matter 
of deployment. I don't think that we can impose anything in this area. There 
are use cases where it is good to have separate router-ids per protocol or 
instances of a protocol. For instance, when a router is part of multiple 
"administrative domains", it is worth having separate router-ids per admin 
domain.

However I have a concern about the router-id or te-node-id  bound to a 32 bits 
number only. How do we do in a pure IPv6 network ?

Brgds,


-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Wednesday, December 05, 2018 12:14
To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org; 
draft-ietf-ospf-y...@ietf.org; draft-ietf-teas-yang-te-ty...@ietf.org
Subject: Re: draft-ietf-ospf-yang

Acee

(Top-posting because the indentation usually fails)

On the TEAS te-types, I had a quick look at where
typedef te-node-id
is used and the answer is lots of places, because it is part of
  grouping explicit-route-hop {
description"The explicit route subobject grouping";
choice type {
  description   "The explicit route subobject type";
  case num-unnum-hop {
container num-unnum-hop {
  leaf node-id {
type te-types:te-node-id;
description   "The identifier of a node in the TE
topology.";
and YANG uses of that grouping are many, in several WGs; however,
because it is a grouping, then the impact of changing the type should be
minimal at least in terms of the I-Ds.

On the multiple router definitions, my research of the IETF memo only
came up with the two cited RFC which, to me, say that you should use an
existing router-id if there is one.

I did look at the documentation of A Major Router Manufacturer and while
they did not give any advice, the default for a te router-id was
loopback0
while the default for a more general router-id, one without te, was
loopback0
which gives me the message, you can make them different but SHOULD NOT
(in IETF terminology).

So while I agree that the two lsr modules should allow per-protocol
configuration, I think that it should carry a health warning in the body
of the I-D that this is not a good idea (I struggle to think of when it
would be a good idea, to use three separate identifiers for, say, BGP
and the two lsr protocols).

Tom Petch

- Original Message -
From: "Acee Lindem (acee)" 
To: "tom petch" ; ;
; ;

Sent: Tuesday, December 04, 2018 7:46 PM

> Hi Tom,
>
> Let me try to explain.
>
> On 12/4/18, 12:44 PM, "tom petch"  wrote:
>
> The router id in this I-D confuse me.
>
> RFC8294 defines
>  typedef router-id { type yang:dotted-quad;
>
> Some implementations configure a global router-id while others only
allow it at the control-plane-protocol level. This is why we have it in
both places.
>
> ospf-yang defines
>  leaf ipv4-router-id { type inet:ipv4-address;
>
> For better or worse, OSPF has a separate TE address that is routable
and referred to as the TE router-id. You'll note that this is part of
the te-rid container in both the OSPF and IS-IS YANG models. We could
add "-te-" to the leaves to avoid confusion.
>
> draft-ietf-teas-yang-te-types defines
>   typedef te-node-id { type yang:dotted-quad;
>  ...   This attribute is mapped to Router ID 
>
> This is just wrong. It is a routable address in the IGP TE extensions.
I've copied the draft authors.
>
> Thanks,
> Acee Lindem
>
>
> Three different YANG types for a router id.
>
> Why?
>
> Behind this, ospf-yang gives as references for a router te id
> RFC3630(V2) and RFC5329(V3).  Reading these, my take is that a
router id
> is needed for te but that the existing id should be used where
possible
> i.e. creating an additional identifier for the same instance of
the same
> entity is A Bad Thing (which sounds like a good general
principle).
> With two objects in the lsr protocols, that would appear to make
at
> least three identifiers for the same instance of the same entity.
>
> Why?
>
> I copy Stephane on this since the same issues apply to the other
lsr
> protocol, mutatis mutandi.
>
> Tom Petch
>
>
>
>


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied 

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.

• 

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 

Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-isis-cfg-24

[stephane.litkowski]

Hi Tom,

Thanks for your comments. I will fix them asap.
Regarding:
" Line length is within the RFC limit but the effect is to spread many of the 
description clauses over multiple lines with indentation of 56 characters, not 
user friendly e.g.
description
"List of max LSP bandwidths for 
different
 priorities.";
"
What's your suggestion on this one ?

Brgds,

-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Tuesday, November 27, 2018 12:11
To: Ebben Aries; yang-doct...@ietf.org
Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org; Tarek Saad (tsaad)
Subject: Re: [Lsr] Yangdoctors last call review of 
draft-ietf-isis-yang-isis-cfg-24

Some quirks in-25

I see lots of YANG reference statements - good - but no mention of them
in the I-D references - not so good.  My list is

5130
5305
5306
5880
5881
6119
6232
7794
7810
7917
8405

Also perhaps
OLD
reference "RFC  - YANG Data Model for Bidirectional
   Forwarding Detection (BFD).Please replace  with
 published RFC
number for draft-ietf-bfd-yang.";

NEW
reference "RFC  - YANG Data Model for Bidirectional
   Forwarding Detection (BFD).

-- Note to RFC Editor Please replace  with published RFC
number for draft-ietf-bfd-yang.";

OLD
  reference "draft-ietf-bfd-yang-xx.txt:
 YANG Data Model for Bidirectional Forwarding
 Detection (BFD)";
NEW
reference "RFC  - YANG Data Model for Bidirectional
   Forwarding Detection (BFD).

-- Note to RFC Editor Please replace  with published RFC
number for draft-ietf-bfd-yang.";


Line length is within the RFC limit but the effect is to spread many of
the description clauses over multiple lines with indentation of 56
characters, not user friendly
e.g.
description
"List of max LSP
bandwidths for different
 priorities.";


Acknowledgements is TBD. I note that the editor list of the YANG module
is somewhat longer than the editor list of the I-D.

I note that the augmentation of interfaces seems to have no conditional
and so will augment all interfaces. I think that this is a generic issue
but do not see it being addressed anywhere.

In a similar vein, you are defining MPLS objects and I am unclear
whether or not those should be conditional, or part of the MPLS YANG
modules or both (copying Tarek for this)

Tom Petch

- Original Message -
From: "Ebben Aries" 
Sent: Tuesday, October 23, 2018 12:45 AM

> Reviewer: Ebben Aries
> Review result: On the Right Track
>
> 1 module in this draft:
> - ietf-i...@2018-08-09.yang
>
> No YANG compiler errors or warnings (from pyang 1.7.5 and yanglint
0.16.54)
>
> "ietf-isis@2018-08-09" module is compatible with the NMDA
architecture.
>
> Module ietf-i...@2018-08-09.yang:
> - Both the description and the draft name reference that this module
is
>   specific to configuration but contains operational state nodes in
addition
>   to RPCs and notifications.  Any wording suggesting this is only
>   configuration should be changed
> - Module description must contain most recent copyright notice per
>
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.1
> - Module description reads "common across all of the vendor
implementations".
>   I don't think this needs to be called out as such as that is the
overall
>   intention of *all* IETF models
> - This module contains '22' features (and the respective OSPF module
currently
>   contains '26').  While it is understood the purpose of these
features in the
>   module, take precaution as to complexity for clients if they need to
>   understand >= quantity of features per module in use on a
>   network-element.  We are going to end up w/ feature explosion to
convey
>   *all* possible features of each network-element leading to
divergence back
>   towards native models at the end of the day.  A large amount of
these
>   feature names could be defined within a more global namespace (e.g.
nsr) but
>   this gives us a granular yet cumbersome approach (e.g. feature
isis:nsr,
>   ospf:nsr, etc..)
> - RPC 'clear-adjacency' does not have any input leaf that covers
clearing a
>   specific neighbor/adjacency (See comments below as well regarding
RPC
>   alignment w/ the OSPF model)
> - RPC 'clear-adjacency' has an input node of 'interface' however this
is just
>   a string type.  Is there any reason this is not a
leafref/if:interface-ref
>   (much like in the OSPF model)
> - Child nodes within a container or list SHOULD NOT replicate the
parent
>   identifier per
>
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.3.
1.
>
>   A case in point is the list /afs/af 

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

[stephane.litkowski]

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.

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

· 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"

· 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 ?

· 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 ?

· Please set default values as much as you can (for instance in 
interface-common-config or interface-physical-link-config or 
interface-config...)

· 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 in 
the other groupings or even create additional ones if required.

· What is the purpose of some empty groupings that you have created ? 
like "ospf-config" or "ospf-state"

· In the multi-topology-area-common-config, you are using a limited 
uint32 type for the default cost while you have defined a uint24 type that you 
can use. It appears also in area-common-config.

On the draft:

· In the overview (§1), reference to 7950 does not appear as a link, 
maybe an XML issue.

· §2.2: s/The topology container/The "topologies" container

Brgds,


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by 

Re: [Lsr] [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

As mentioned, you could not be aware of all the constraints that we have and 
BGP 3107 is not an option.
Note that this kind of redistribution can even happen within a single AS. We 
had some OSPF domain prefixes leaked in the ISIS L2 in the past in a single AS. 
Nothing prevents this design to come back again.

From: 徐小虎(义先) [mailto:xiaohu@alibaba-inc.com]
Sent: Tuesday, November 20, 2018 09:35
To: spring; Aijun Wang; LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

If I understood it correctly, draft-wang-lsr-ospf-prefix-originator-ext-00 is 
an OSPF counterpart of RFC7794 from the perspective of correlation of prefixes 
and their originator in the inter-area scenario. As such, these two drafts are 
useful for the usage of ELC in the inter-area scenario.

As for the inter-AS scenario, IMHO, BGP LSP over SR LSP is the best choice. In 
other words, I doubt the necessity of advertising the ELC across ASes VIA IGP 
REDISTRIBUTION.

Best regards,
Xiaohu
--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 14:52
To:Aijun Wang ; stephane.litkow...@orange.com 
; lsr@ietf.org 
Cc:spr...@ietf.org 
Subject:Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Aijun –

In the inter-AS case, what is needed is to know ELC of the originating node. 
Simply knowing who the originator of an advertisement is not sufficient.

If ELC is advertised as a node capability, then a controller with access to 
BGP-LS database for both ASs could determine ELC by piecing together the node 
capability advertisement and the prefix advertisement w originating router-id.

But what Stephane has proposed for the inter-AS case is a way to know ELC in 
the absence of a controller.
This means nodes in AS #1 need to have ELC capability info for nodes in AS #2.
As there is no way to redistribute IGP Node Capability advertisements between 
different IGP instances, the alternative is to advertise ELC associated with a 
prefix advertisement since the prefix advertisement can be redistributed 
between IGP instances.
Knowing the originator of the prefix is necessary, but it is not sufficient.

Hope this is clear.

Les



From: Aijun Wang 
Sent: Monday, November 19, 2018 10:41 PM
To: Les Ginsberg (ginsberg) ; 
stephane.litkow...@orange.com; lsr@ietf.org
Cc: spr...@ietf.org
Subject: 答复: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi, Les and Stephane:

https://tools.ietf.org/html/draft-wang-lsr-ospf-prefix-originator-ext-00 is 
trying to solve what you are concerning for.
As you said, ELC/ERLD are functionally node capabilities, but when we try to 
send traffic, we should consider the prefixes itself.
The above draft proposal to add prefix originator to address this. After 
getting this information, the receiver can then build the relationship between 
prefixes and ELC/ERLD.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2018年11月20日 2:00
收件人: stephane.litkow...@orange.com; 
l...@ietf..org
抄送: spr...@ietf.org
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: lsr@ietf.org
Cc: spr...@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per 

Re: [Lsr] [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

We can’t for some internal design/security reasons.

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Tuesday, November 20, 2018 09:10
To: spring; Lsr; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Re: [Lsr] [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Why not directly use the BGP over SR model just like the BGP over LDP model?

Best regards,
Xiaohu

--
From:stephane.litkowski 
Send Time:2018年11月20日(星期二) 15:20
To:徐小虎(义先) ; Lsr ; 
lsr@ietf.org 
Cc:spr...@ietf.org 
Subject:Re: [spring] [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

The use case is without TE. And this is how network designs are working today, 
and I do not see any valid reason to complexify and change the existing designs 
by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is 
quite simple.

Brgds,

From:徐小虎(义先) [mailto:xiaohu@alibaba-inc.com]
Sent: Tuesday, November 20, 2018 03:16
To: Lsr; LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

IMHO, it seems a little bit odd to support inter-AS TE scenarios in the absence 
of a controller. If the inter-AS scenario is not for the TE purpose, would the 
(inter-AS) BGP-initiated LSP over (intra-AS) SR-initiated LSP be good enough 
(just like what we have done before in the LDP era, i.e., the BGP-initiated LSP 
over LDP-initiated LSP)?

Best regards,
Xiaohu

--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 02:00
To:stephane.litkow...@orange.com ; lsr@ietf.org 

Cc:spr...@ietf.org 
Subject:Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr  On Behalf Of stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: lsr@ietf.org
Cc: spr...@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be associated to the 
prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for 
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes 
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by 
a local configuration and for leaked/redistributed prefixes. When a prefix is 
leaked or redistributed, the ELC associated to the prefix may be also 
leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the 
prefix associated to the Node/Prefix segment as the ELC set in the Prefix 
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the 
adjacent neighbor of the node that has advertised the Adj SID is advertising an 
ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not 

Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

Hi all,

The use case is without TE. And this is how network designs are working today, 
and I do not see any valid reason to complexify and change the existing designs 
by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is 
quite simple.

Brgds,

From: 徐小虎(义先) [mailto:xiaohu@alibaba-inc.com]
Sent: Tuesday, November 20, 2018 03:16
To: Lsr; LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi all,

IMHO, it seems a little bit odd to support inter-AS TE scenarios in the absence 
of a controller. If the inter-AS scenario is not for the TE purpose, would the 
(inter-AS) BGP-initiated LSP over (intra-AS) SR-initiated LSP be good enough 
(just like what we have done before in the LDP era, i.e., the BGP-initiated LSP 
over LDP-initiated LSP)?

Best regards,
Xiaohu

--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 02:00
To:stephane.litkow...@orange.com ; lsr@ietf.org 

Cc:spr...@ietf.org 
Subject:Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr  On Behalf Of stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: lsr@ietf.org
Cc: spr...@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be associated to the 
prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for 
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes 
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by 
a local configuration and for leaked/redistributed prefixes. When a prefix is 
leaked or redistributed, the ELC associated to the prefix may be also 
leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the 
prefix associated to the Node/Prefix segment as the ELC set in the Prefix 
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the 
adjacent neighbor of the node that has advertised the Adj SID is advertising an 
ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not involved in the signaling of the binding 
SID, there is nothing to do in these drafts.


Let us know your comments/feedback on this proposal so we can progress these 
documents.

Brgds,

Stephane


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 

[Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[stephane.litkowski]

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn't found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be associated to the 
prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for 
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes 
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by 
a local configuration and for leaked/redistributed prefixes. When a prefix is 
leaked or redistributed, the ELC associated to the prefix may be also 
leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the 
prefix associated to the Node/Prefix segment as the ELC set in the Prefix 
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the 
adjacent neighbor of the node that has advertised the Adj SID is advertising an 
ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not involved in the signaling of the binding 
SID, there is nothing to do in these drafts.


Let us know your comments/feedback on this proposal so we can progress these 
documents.

Brgds,

Stephane


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

[stephane.litkowski]

Hi,

As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD means 
that the node is defacto ELC (so advertising ELC separately is not necessary):

" The Entropy Readable Label Depth (ERLD) is defined as the number of
   labels a router can both:

   a.  Read in an MPLS packet received on its incoming interface(s)
   (starting from the top of the stack).

   b.  Use in its load-balancing function.

   The ERLD means that the router will perform load-balancing using the
   EL label if the EL is placed within the ERLD first labels.
"

"
To advertise an ERLD value, a SPRING router:

   o  MUST be entropy label capable and, as a consequence, MUST apply
  the dataplane procedures defined in [RFC6790].

   o  MUST be able to read an ELI/EL which is located within its ERLD
  value.

   o  MUST take into account this EL in its load-balancing function.
"


Brgds,


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde, Gunter 
(Nokia - BE/Antwerp)
Sent: Wednesday, June 13, 2018 11:10
To: Ketan Talaulikar (ketant); i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are 
signaled for ISIS, OSPF and BGP-LS. 

If the WG's can manage to agree upon a decision (option1/2/3 or 4), then next, 
have a look into how to encode the TLV so that we have a clean technological 
solution space.

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 10:45
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

In that case, I concur with you that option (2) is better than the others. My 
only difference in opinion is that ERLD not have its own separate TLV but 
instead get advertised as a new MSD sub-type - it is just a different encoding.

Thanks,
Ketan

-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp)  
Sent: 13 June 2018 13:55
To: Ketan Talaulikar (ketant) ; i...@ietf.org; lsr@ietf.org; 
spr...@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic 
motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is 
available, then ELC can be implicitly assumed. No pragmatic reason to signal 
separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both 
>IGP and BGP-LS encoding seems to make little sense and only bring confusion 
>(router/controller implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive 
confusion)
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of 
ELC TLV compared to option (2))
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more 
complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators
* most simple solution for implementers (routers and controller)
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability 
which is advertised differently than ERLD which is a limit. Are you saying that 
ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in 
the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. 
This way we have the flexibility of signalling ERLD both per node and per 
ingress link/LC level.

Thanks,
Ketan

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: 12 June 2018 19:28
To: i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is 
signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[stephane.litkowski]

I’m not aware of non-disclosed IPR.


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Uma Chunduri
Sent: Monday, June 11, 2018 21:18
To: lsr@ietf.org
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 
(Shepherd write-up)

Dear All,

Are you aware of any IPR that applies to
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?

Sending this email as suggested by LSR chairs - as this was not noticed 
during/around WGLC.

===
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.
===

--
Uma C.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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