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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
