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

[tom petch <[e-mail]>]

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

> Hi Tom,
>
> Let me try to explain.
>
> On 12/4/18, 12:44 PM, "tom petch" <[e-mail]> 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
>
>
>
>