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