Hi Acee, Tom, and All, Several authors of draft-ietf-teas-yang-te-types had a brief discussion on this topic. Our take on the te-node-id and te-router-id is:
- In TEAS, the te-node-id specified in draft-ietf-teas-yang-te-types has a wider use scope than IP MPLS TE. The system may or may not run OSPF TE, and may not use IPv4. The 32-bit ID number is used only for uniquely identifying the TE node, and it may or may not be a routable address. - When RFC3630 is implemented, it is ok to map a routable IPv4 address (such as the address of loopbak0) to the te-node-id, but it is not required.. - We intentionally use the term "te-node-id" instead of "te-router-id" to convey the concept that this ID is on a TE node, which may or may or be a router. - We will clarify the description to say that "This attribute is MAY be mapped to TE Router ID in [RFC3630], [RFC5329], [RFC5305], and [RFC6119]." Thanks, - Xufeng On Thu, Dec 6, 2018 at 12:38 PM Acee Lindem (acee) <[email protected]> wrote: > 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
