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

From: tom petch <[email-masked]>
Date: Tue, 4 Dec 2018 17:44:53 +0000

The router id in this I-D confuse me.

RFC8294 defines
     typedef router-id { type yang:dotted-quad;

ospf-yang defines
 leaf ipv4-router-id { type inet:ipv4-address;

draft-ietf-teas-yang-te-types defines
  typedef te-node-id {     type yang:dotted-quad;
 ...       This attribute is mapped to Router ID ....

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 4 Dec 2018 19:46:07 +0000

Hi Tom, 

Let me try to explain. 

On 12/4/18, 12:44 PM, "tom petch" <[email-masked]> wrote:

    RFC8294 defines

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

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. 

This is just wrong. It is a routable address in the IGP TE extensions. I've copied the draft authors. 

Thanks,
Acee Lindem

    Why?

    Why?

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Wed, 5 Dec 2018 11:13:54 +0000

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)" <[email-masked]>
To: "tom petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, December 04, 2018 7:46 PM

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

---

From: <[email-masked]>
Date: Wed, 5 Dec 2018 12:57:17 +0000

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:[email-masked]] 
Sent: Wednesday, December 05, 2018 12:14
To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS; [email-masked]; [email-masked]; [email-masked]
Subject: Re: draft-ietf-ospf-yang

Acee

Tom Petch

----- Original Message -----
From: "Acee Lindem (acee)" <[email-masked]>
To: "tom petch" <[email-masked]>; <[email-masked]>;

>     protocol, mutatis mutandi.

_________________________________________________________________________________________________________________________

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.

---

From: tom petch <[email-masked]>
Date: Wed, 5 Dec 2018 16:11:56 +0000

----- Original Message -----
From: <[email-masked]>
Sent: Wednesday, December 05, 2018 12:57 PM

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

Stephane

I am used to configuring a router-id as a 32-bit number with no
requirement for that to be an address that can be accessed over the
internet (so I have always found the idea of 'loopback0' unfortunate).
Yes, the router needs to be addressable, but merging that concept with a
router id has always seemed to me unfortunate because they are two
separate concepts.  (In fact, I would regard good practice as giving a
router multiple addresses for different functions, so that e.g. syslog
can be separated from SNMP or FTP).

Thus I have no problem with a 32-bit router-id in an IPv6 network.
Indeed, RFC5329 defines a 32-bit router-id in an OSPFv3
Intra-Area-TE-LSA.  It is the Router IPv6 Address TLV that carries the
128-bit address.

When ospf-yang says
         container te-rid {
           if-feature te-rid;
           description  "Stable OSPF Router IP Address used for Traffic
              Engineering (TE)";
           leaf ipv4-router-id { type inet:ipv4-address; description
               "Explicitly configure the TE IPv4 Router ID.";
           }
           leaf ipv6-router-id {
             type inet:ipv6-address;
             description "Explicitly configure the TE IPv6 Router ID.";

then that is when I wonder what is going on.  That looks to me like
configuring
Router IPv6 Address TLV
not the router id.

Meanwhile, te-yang-te-types has

   te-node-id:
      A type representing the identifier for a node in a topology.  The
      identifier is represented as 32-bit unsigned integer in the
      dotted-quad notation.  This attribute is mapped to Router ID in
      [RFC3630], [RFC5329], [RFC5305], and [RFC6119].

Well, I disagree with their choice of YANG type but agree that it is
32-bit and not 128.

Tom Petch.

> To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS; [email-masked];
[email-masked]; [email-masked]
> > This is just wrong. It is a routable address in the IGP TE
extensions.
> I've copied the draft authors.
> >
> > Thanks,
> > Acee Lindem
> >
> >
________________________________________________________________________
_________________________________________________
>
> 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,
> This message and its attachments may contain confidential or
privileged information that may be protected by law;

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Dec 2018 17:37:51 +0000

Hi Tom, 
I think the only action here is for the authors of draft-ietf-teas-yang-te-types to fix their te-node-id definition. As for the OSPF Router ID and OSPF/ISIS TE Router IDs we can't change the decades old definitions to achieve uniformity. 
Thanks,
Acee

On 12/5/18, 11:12 AM, "tom petch" <[email-masked]> wrote:

    ----- Original Message -----
    From: <[email-masked]>
    Sent: Wednesday, December 05, 2018 12:57 PM

    Stephane

    
    When ospf-yang says
             container te-rid {
               if-feature te-rid;

    
       te-node-id:

    Tom Petch.
    
    extensions.

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 6 Dec 2018 17:02:38 -0500

Hi Acee, Tom, and All,

Several authors of draft-ietf-teas-yang-te-types had a brief discussion on
this topic. Our take on the te-node-id and te-router-id is:

- In TEAS, the te-node-id specified in draft-ietf-teas-yang-te-types has a
wider use scope than IP MPLS TE. The system may or may not run OSPF TE, and
may not use IPv4. The 32-bit ID number is used only for uniquely
identifying the TE node, and it may or may not be a routable address.
- When RFC3630 is implemented, it is ok to map a routable IPv4 address
(such as the address of loopbak0) to the te-node-id, but it is not required.
- We intentionally use the term "te-node-id" instead of "te-router-id" to
convey the concept that this ID is on a TE node, which may or may or be a
router.
- We will clarify the description to say that "This attribute is MAY be
mapped to TE Router ID in [RFC3630], [RFC5329], [RFC5305], and [RFC6119]."

Thanks,
- Xufeng

On Thu, Dec 6, 2018 at 12:38 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Tom,
> I think the only action here is for the authors of
> draft-ietf-teas-yang-te-types to fix their te-node-id definition. As for
> the OSPF Router ID and OSPF/ISIS TE Router IDs we can't change the decades
> old definitions to achieve uniformity.
> Thanks,
> Acee
>
>     > >     With two objects in the lsr protocols, that would appear to
> make
>     > at
>     > >     I copy Stephane on this since the same issues apply to the
> other
>     > lsr
>     > If you have received this email in error, please notify the sender
> and
>     delete this message and its attachments.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 7 Dec 2018 00:26:50 +0000

Hi Xufeng,
Sounds good.
Acee

From: Xufeng Liu <[email-masked]>
Date: Thursday, December 6, 2018 at 5:03 PM
To: Acee Lindem <[email-masked]>
Cc: Tom Petch <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-ospf-yang

Hi Acee, Tom, and All,

Several authors of draft-ietf-teas-yang-te-types had a brief discussion on this topic. Our take on the te-node-id and te-router-id is:

- In TEAS, the te-node-id specified in draft-ietf-teas-yang-te-types has a wider use scope than IP MPLS TE. The system may or may not run OSPF TE, and may not use IPv4. The 32-bit ID number is used only for uniquely identifying the TE node, and it may or may not be a routable address.
- When RFC3630 is implemented, it is ok to map a routable IPv4 address (such as the address of loopbak0) to the te-node-id, but it is not required.
- We intentionally use the term "te-node-id" instead of "te-router-id" to convey the concept that this ID is on a TE node, which may or may or be a router.
- We will clarify the description to say that "This attribute is MAY be mapped to TE Router ID in [RFC3630], [RFC5329], [RFC5305], and [RFC6119]."

Thanks,
- Xufeng

On Thu, Dec 6, 2018 at 12:38 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,
I think the only action here is for the authors of draft-ietf-teas-yang-te-types to fix their te-node-id definition. As for the OSPF Router ID and OSPF/ISIS TE Router IDs we can't change the decades old definitions to achieve uniformity.
Thanks,
Acee

On 12/5/18, 11:12 AM, "tom petch" <[email-masked]<mailto:[email-masked]>> wrote:

    ----- Original Message -----
    From: <[email-masked]<mailto:[email-masked]>>
    Sent: Wednesday, December 05, 2018 12:57 PM

    Stephane

    When ospf-yang says
             container te-rid {
               if-feature te-rid;

       te-node-id:

    Tom Petch.

    > From: tom petch [mailto:[email-masked]<mailto:[email-masked]>]
    > To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>;
    [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
    > From: "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
    > To: "tom petch" <[email-masked]<mailto:[email-masked]>>;
    <[email-masked]<mailto:[email-masked]>>;
    > <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
    > <[email-masked]<mailto:[email-masked]>>
    > > On 12/4/18, 12:44 PM, "tom petch" <[email-masked]<mailto:[email-masked]>> wrote:
    > >
    extensions.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 7 Dec 2018 17:02:34 +0000

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 <[email-masked]>
Date: Thursday, November 29, 2018 at 5:44 AM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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:[email-masked]]
Sent: Wednesday, November 28, 2018 18:09
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]; [email-masked]
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

Hi Stephane,

From: Stephane Litkowski <[email-masked]>
Date: Wednesday, November 28, 2018 at 7:04 AM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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:[email-masked]]
Sent: Tuesday, November 27, 2018 23:53
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]; [email-masked]
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 <[email-masked]>
Date: Wednesday, November 21, 2018 at 5:34 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Resent-From: <[email-masked]>
Resent-To: Derek Yeung <[email-masked]>, Yingzhen Qu <[email-masked]>, Jeffrey Zhang <[email-masked]>, <[email-masked]>, Acee Lindem <[email-masked]>
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 in the other groupings or even create additional ones if required.
I’m not sure I disagree with the groupings. There are other possible hierarchies but this seems to work.

•         What is the purpose of some empty groupings that you have created ? like “ospf-config” or “ospf-state”
These are meant to be augmented for top-level config and stats.

Thanks,
Acee

•         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]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>  NEW !
mobile: +33 6 71 63 27 50 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>  NEW !
[email-masked]<mailto:[email-masked]>

Thank you.

Thank you.

Thank you.

---

From: tom petch <[email-masked]>
Date: Fri, 7 Dec 2018 17:14:49 +0000

----- Original Message -----
From: "Xufeng Liu" <[email-masked]>
Subject: Re: draft-ietf-ospf-yang

Hi Acee, Tom, and All,

Several authors of draft-ietf-teas-yang-te-types had a brief discussion
on
this topic. Our take on the te-node-id and te-router-id is:

- In TEAS, the te-node-id specified in draft-ietf-teas-yang-te-types has
a
wider use scope than IP MPLS TE. The system may or may not run OSPF TE,
and
may not use IPv4. The 32-bit ID number is used only for uniquely
identifying the TE node, and it may or may not be a routable address.
- When RFC3630 is implemented, it is ok to map a routable IPv4 address
(such as the address of loopbak0) to the te-node-id, but it is not
required.
- We intentionally use the term "te-node-id" instead of "te-router-id"
to
convey the concept that this ID is on a TE node, which may or may or be
a
router.
- We will clarify the description to say that "This attribute is MAY be
mapped to TE Router ID in [RFC3630], [RFC5329], [RFC5305], and
[RFC6119]."

<tp>

Xufeng

Thanks for the clarification - I understand better now.

However, I think that your proposed text is not quite right.  RFC5329
does not defined a TE Router ID - in fact, I think that that concept is
alien to OSPF.  OSPF has a 32 bit number that is the Router ID with no
requirement for that to be a routable address; which is why (IMHO)
RFC5329 defines a
Router IPv6 Address TLV
which carries a routable address (which can meet the needs of TE).

Likewise, RFC3630, for OSPFv2, does not have the concept of a TE Router
ID; rather, it has a
Router Address TLV
which specifies a stable IP address (which can meet the needs of TE).

And then there is RFC5786 which defines, for OSPF,  the
Node Attribute TLV
with sub-TLV for
Node IPv4 Local Address
Node IPv6 Local Address
allowing for multiple TE addresses for different traffic types.

I grant you that RFC6119 defines a
 TE Router ID
but the concept is alien to OSPF (IMHO).

So, if you want to use the term
 TE Router ID
then I think that you will need to explain how that maps onto the
terminology of the existing OSPF RFC.

Tom Petch

Thanks,
- Xufeng

On Thu, Dec 6, 2018 at 12:38 PM Acee Lindem (acee) <[email-masked]>
wrote:

>     > I think that having a different router-id configured per
protocol is
> a
>     > However I have a concern about the router-id or te-node-id
bound to
> a
>     Yes, the router needs to be addressable, but merging that concept
with
> a
description
>     > because it is a grouping, then the impact of changing the type
should
>     be
>     > came up with the two cited RFC which, to me, say that you should
use
>     an
>     > I did look at the documentation of A Major Router Manufacturer
and
>     while
>     > which gives me the message, you can make them different but
SHOULD
> NOT
>     > 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
>     > allow it at the control-plane-protocol level. This is why we
have it
>     in
>     > >     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
>     > pas etre diffuses, exploites ou copies sans autorisation. Si
vous
> avez
>     > As emails may be altered, Orange is not liable for messages that
have
>     been modified, changed or falsified.
>     > Thank you.
>     >
>     >
>
>
>
>

---

From: <[email-masked]>
Date: Mon, 10 Dec 2018 09:15:42 +0000

Hi Acee,

I’m fine with that.

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Friday, December 07, 2018 18:03
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]; [email-masked]
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

Hi Stephane,

Hi Acee,

Hi Stephane,

Hi Acee,

Thanks,
Acee

Brgds,

Hey Stephane,

Hi,

Thanks,
Acee

On the draft:

Brgds,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 10 Dec 2018 09:54:16 +0000

Acee and  co-authors,

The last version of the model has a compilation failed status in the YANG catalog.
https://yangcatalog.org/results/[email-masked]

Could you check what’s going on ?

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 10, 2018 10:16
To: Acee Lindem (acee); [email-masked]; [email-masked]
Subject: Re: [Lsr] Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

Hi Acee,

I’m fine with that.

Hi Stephane,

Hi Acee,

Hi Stephane,

Hi Acee,

Thanks,
Acee

Brgds,

Hey Stephane,

Hi,

Thanks,
Acee

On the draft:

Brgds,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Dec 2018 13:02:05 +0000

Hi Stephane,
I will be posting new version this week but will check with Benoit and Joe as to why this isn’t getting updated.
Thanks,
Acee

From: Stephane Litkowski <[email-masked]>
Date: Monday, December 10, 2018 at 4:54 AM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

Acee and  co-authors,

Hi Acee,

I’m fine with that.

Hi Stephane,

Hi Acee,

Hi Stephane,

Hi Acee,

Thanks,
Acee

Brgds,

Hey Stephane,

Hi,

Thanks,
Acee

On the draft:

Brgds,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 10 Dec 2018 09:47:11 -0500

Hi Tom,

Thanks for checking on this. Agree that we need to fix the description
text. What about the following?

te-node-id:
      A type representing the identifier for a node in a TE topology.  The
identifier is represented as 32-bit unsigned integer in the dotted-quad
notation.  This attribute MAY be mapped to the Router Address described in
Section 2.4.1 of [RFC3630], the TE Router ID described in Section 3 of
[RFC6827], the Traffic Engineering Router ID described in Section 4.3 of
[RFC5305], or the TE Router ID described in Section 3.2.1 of [RFC6119]. The
reachability of such a TE node MAY be achieved by a mechanism such as
Section 6.2 of [RFC6827].

Or, would you give a suggestion?

Thanks,
- Xufeng

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Dec 2018 15:44:24 +0000

I tried http://www.yangvalidator.com/draft-validator on my most recent update and it finished with no errors. However, there was an internal error in pyang (+Martin):

Traceback (most recent call last):
pyang", line 444, in <module>
    run()
pyang", line 219, in run
    repos = pyang.FileRepository(path, no_path_recurse=o.no_path_recurse)
__init__.py", line 408, in __init__
    location = pip.locations.distutils_scheme('pyang')
AttributeError: 'module' object has no attribute 'locations'

Thanks,
Acee

Acee and  co-authors,

Hi Acee,

I’m fine with that.

Hi Stephane,

Hi Acee,

Hi Stephane,

Hi Acee,

Thanks,
Acee

Brgds,

Hey Stephane,

Hi,

Thanks,
Acee

On the draft:

Brgds,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: tom petch <[email-masked]>
Date: Tue, 11 Dec 2018 12:25:39 +0000

----- Original Message -----
From: "Xufeng Liu" <[email-masked]>
Sent: Monday, December 10, 2018 2:47 PM

Hi Tom,

te-node-id:
      A type representing the identifier for a node in a TE topology.
The
identifier is represented as 32-bit unsigned integer in the dotted-quad
notation.  This attribute MAY be mapped to the Router Address described
in
Section 2.4.1 of [RFC3630], the TE Router ID described in Section 3 of
[RFC6827], the Traffic Engineering Router ID described in Section 4.3 of
[RFC5305], or the TE Router ID described in Section 3.2.1 of [RFC6119].
The
reachability of such a TE node MAY be achieved by a mechanism such as
Section 6.2 of [RFC6827].

<tp>

Looks good.

One query I cannot answer; should
  RFC5786 Advertising a Router's Local Addresses in OSPF
     TE Extensions. R. Aggarwal, K. Kompella. March 2010
be there as well?  On the face of it, it looks relevant and would appear
to meet a need but I note its absence from ospf-yang; I do not know how
widely it is implemented or used.  This RFC is updated by RFC6827.

Tom Petch

Thanks,
- Xufeng

On Fri, Dec 7, 2018 at 12:14 PM tom petch <[email-masked]> wrote:

> >     matter of deployment. I don't think that we can impose anything
in
> this
> >     Intra-Area-TE-LSA.  It is the Router IPv6 Address TLV that
carries
> >                  description "Explicitly configure the TE IPv6
Router
> ID.";
> >           A type representing the identifier for a node in a
topology.
> The
> >           dotted-quad notation.  This attribute is mapped to Router
ID
> >     Well, I disagree with their choice of YANG type but agree that
it
> is
> >     > On the multiple router definitions, my research of the IETF
memo
> only
> >     > while the default for a more general router-id, one without
te,
> was
> >     > > Some implementations configure a global router-id while
others
> only
> >     > the te-rid container in both the OSPF and IS-IS YANG models.
We
> could
> >     > >     Behind this, ospf-yang gives as references for a router
te
> id
> >     > >     least three identifiers for the same instance of the
same
> >     entity.
> >     > Orange decline toute responsabilite si ce message a ete
altere,
> >     deforme ou falsifie. Merci.
> >     >

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 11 Dec 2018 23:25:12 -0500

> widely it is implemented or used.  This RFC is updated by RFC6827.

RFC6827 uses RFC5786, making it more generic and more complete, I think.
As you said, RFC6827 has updated RFC5786, which is cited heavily in
RFC6827. So, logically RFC5786 is already covered. Since RFC5786 does not
provide a TE Router ID mapping by itself, I could not figure out a concise
wording to cite it separately, so I felt that RFC6827 would be more
relevant. Any suggestion would be appreciated.
Thanks,
- Xufeng

---

From: tom petch <[email-masked]>
Date: Wed, 12 Dec 2018 12:35:08 +0000

----- Original Message -----
From: "Xufeng Liu" <[email-masked]>
Sent: Wednesday, December 12, 2018 4:25 AM
Subject: Re: draft-ietf-ospf-yang

> identifier is represented as 32-bit unsigned integer in the
dotted-quad

RFC6827 uses RFC5786, making it more generic and more complete, I think.
As you said, RFC6827 has updated RFC5786, which is cited heavily in
RFC6827. So, logically RFC5786 is already covered. Since RFC5786 does
not
provide a TE Router ID mapping by itself, I could not figure out a
concise
wording to cite it separately, so I felt that RFC6827 would be more
relevant. Any suggestion would be appreciated.

<tp>

On reflection, leave it as it is; the text in RFC6827 is, overall,
clearer than RFC5786.

On an unrelated topic, te-types has references in the YANG module to
RFC7823 - good - but this RFC does not appear in the References for the
ID - not so good.  Having added it, you will need a reference to it in
the text of the I-D lest you get an unused reference.  Common practice
is to have a section preceding the module along the lines of
"This module imports [ ..] and references [....].  3.1 has the imports
but not the references.

And it is expected to have references for imports, e.g.
     import ietf-inet-types {
       prefix "inet";
       reference "RFC 6991 - Common YANG Data Types";

Tom Petch

Thanks,
- Xufeng

> > > draft-ietf-teas-yang-te-types to fix their te-node-id definition.
As
> > for
> > >     requirement for that to be an address that can be accessed
over
> > >     router multiple addresses for different functions, so that
e.g.
> > syslog
> > >                description  "Stable OSPF Router IP Address used
for
> > Traffic
> > >     > > 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
> > >     > >     entity is A Bad Thing (which sounds like a good
general
> > >     > principle).
> > >     > >     With two objects in the lsr protocols, that would
appear

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 Dec 2018 20:14:23 +0000

Hi Tom, Xufeng, 
There are definitely some TE and GMPLS encodings including RFC 6827 and RFC 5786 that are not in this version of the model. However, the model has reached the point in both size and maturity where these can go in augmentations if they are important. If not, the LSAs will still be available as a hex string. 

   leaf raw-data {
      type yang:hex-string;
      description
        "The complete LSA in network byte                                                                                                                                                                                     
         order hexadecimal as received or originated.";
    }

We have augmentations in process for both segment-routing and OSPFv3 Extended LSAs in progress. We will undoubtedly have others and additional operational data. 

Thanks,
Acee 

On 12/12/18, 7:35 AM, "tom petch" <[email-masked]> wrote:

    ----- Original Message -----
    From: "Xufeng Liu" <[email-masked]>
    Sent: Wednesday, December 12, 2018 4:25 AM
    Subject: Re: draft-ietf-ospf-yang

    dotted-quad

    <tp>

    
    
    Tom Petch
    
    Thanks,
    - Xufeng
    
    As
    over
    e.g.
    for
    is
    is
    general
    appear

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 12 Dec 2018 23:00:46 -0500

Hi Tom,

Thanks for the kind suggestion. We will include these fixes in the next
revision of draft-ietf-teas-yang-te-types.
Best regards,
- Xufeng

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

> > > >     been modified, changed or falsified.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---

From: tom petch <[email-masked]>
Date: Fri, 14 Dec 2018 17:44:07 +0000

---- Original Message -----
From: "Acee Lindem (acee)" <[email-masked]>
Sent: Wednesday, December 12, 2018 8:14 PM

> Hi Tom, Xufeng,
> There are definitely some TE and GMPLS encodings including RFC 6827
and RFC 5786 that are not in this version of the model. However, the
model has reached the point in both size and maturity where these can go
in augmentations if they are important. If not, the LSAs will still be
available as a hex string.
> We have augmentations in process for both segment-routing and OSPFv3
Extended LSAs in progress. We will undoubtedly have others and
additional operational data.

Acee

Ok.

Where I think that ospf-yang needs a tweak still is in
" 15.  te-rid: Support configuration of the Traffic Engineering (TE)
    Router-ID [RFC3630], [RFC5329]. "
since RFC3630 does not contain that phrase, nor does RFC5329.

I think that the text proposed by Xufeng for teas-types handles this
issue rather well and so would propose

" 15.  te-rid: Support configuration of the Traffic Engineering (TE)
    Router-ID i.e. the Router Address described  in  Section 2.4.1 of
[RFC3630] or the Router IPv6 Address TLV described in Section 3 of
[RFC5329].

Tom Petch

>     > [RFC6827], the Traffic Engineering Router ID described in
Section 4.3
>     of
>     > be there as well?  On the face of it, it looks relevant and
would
>     appear
>     > to meet a need but I note its absence from ospf-yang; I do not
know
>     how
>     > > - In TEAS, the te-node-id specified in
draft-ietf-teas-yang-te-types
>     > has
>     > > a
>     > > wider use scope than IP MPLS TE. The system may or may not run
OSPF
>     > TE,
>     > > convey the concept that this ID is on a TE node, which may or
may or
>     > be
>     > > a
>     > > router.
>     > > - We will clarify the description to say that "This attribute
is MAY
>     > > does not defined a TE Router ID - in fact, I think that that
concept
>     > is
>     > > alien to OSPF.  OSPF has a 32 bit number that is the Router ID
with
>     no
>     > > Likewise, RFC3630, for OSPFv2, does not have the concept of a
TE
>     > Router
>     > > ID; rather, it has a
>     > > Router Address TLV
>     > > which specifies a stable IP address (which can meet the needs
of
>     TE).
>     > > > the OSPF Router ID and OSPF/ISIS TE Router IDs we can't
change the
>     > > decades
>     > > >     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
>     > > >     I am used to configuring a router-id as a 32-bit number
with
>     no
>     > > >     Yes, the router needs to be addressable, but merging
that
>     > concept
>     > > with
>     > > > a
>     > > >     router id has always seemed to me unfortunate because
they are
>     > two
>     > > >     separate concepts.  (In fact, I would regard good
practice as
>     > > giving a
>     > > >     Thus I have no problem with a 32-bit router-id in an
IPv6
>     > network.
>     > > >     then that is when I wonder what is going on.  That looks
to me
>     > > like
>     > > >           identifier is represented as 32-bit unsigned
integer in
>     > > >     > is used and the answer is lots of places, because it
is part
>     > of
>     > > >     >             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
>     > > >     > came up with the two cited RFC which, to me, say that
you
>     > > >     > they did not give any advice, the default for a te
router-id
>     > > >     > 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
>     > > >     > > On 12/4/18, 12:44 PM, "tom petch"
<[email-masked]>
>     > > >     > >     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
>     > > >     > >     I copy Stephane on this since the same issues
apply to

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 14 Dec 2018 18:04:08 +0000

Hi Tom, 

On 12/14/18, 12:44 PM, "tom petch" <[email-masked]> wrote:

    ---- Original Message -----
    From: "Acee Lindem (acee)" <[email-masked]>
    Sent: Wednesday, December 12, 2018 8:14 PM

    Acee
    
    Ok.

    

Yes - I will add this. 

Thanks,
Acee
    
    Tom Petch
    
    Section 4.3
    would
    know
    OSPF
    may or
    is MAY
    concept
    with
    TE
    of
    change the
    separate
    when a
    having
    with
    that
    they are
    practice as
    IPv6
    to me
    integer in
    is part
    the
    WGs;
    the
    you
    router-id
    warning
    think
    identifiers for,
    <[email-masked]>
    take
    be
    apply to