----- 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
