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

[tom petch <[e-mail]>]

----- Original Message -----
From: <[e-mail]>
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.

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