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:ie...@btconnect.com] Sent: Wednesday, December 05, 2018 12:14 To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org; draft-ietf-ospf-y...@ietf.org; draft-ietf-teas-yang-te-ty...@ietf.org 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)" <a...@cisco.com> To: "tom petch" <ie...@btconnect.com>; <stephane.litkow...@orange.com>; <lsr@ietf.org>; <draft-ietf-ospf-y...@ietf.org>; <draft-ietf-teas-yang-te-ty...@ietf.org> Sent: Tuesday, December 04, 2018 7:46 PM > Hi Tom, > > Let me try to explain. > > On 12/4/18, 12:44 PM, "tom petch" <ie...@btconnect.com> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr