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 protected]> wrote: ----- Original Message ----- From: <[email protected]> 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:[email protected]] > Sent: Wednesday, December 05, 2018 12:14 > To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS; [email protected]; [email protected]; [email protected] > 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)" <[email protected]> > To: "tom petch" <[email protected]>; <[email protected]>; > <[email protected]>; <[email protected]>; > <[email protected]> > Sent: Tuesday, December 04, 2018 7:46 PM > > > Hi Tom, > > > > Let me try to explain. > > > > On 12/4/18, 12:44 PM, "tom petch" <[email protected]> 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. > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
