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

[<[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, December 05, 2018 12:14
To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS; [e-mail]; [e-mail]; [e-mail]
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)" <[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
>
>
>
>


_________________________________________________________________________________________________________________________

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.