Re: [Lsr] draft-ietf-ospf-yang

[tom petch <[e-mail]>]

---- Original Message -----
From: "Acee Lindem (acee)" <[e-mail]>
Sent: Wednesday, December 12, 2018 8:14 PM

> Hi Tom, Xufeng,
> There are definitely some TE and GMPLS encodings including RFC 6827
and RFC 5786 that are not in this version of the model. However, the
model has reached the point in both size and maturity where these can go
in augmentations if they are important. If not, the LSAs will still be
available as a hex string.
>
>    leaf raw-data {
>       type yang:hex-string;
>       description
>         "The complete LSA in network  byte
>          order hexadecimal as received or originated.";
>     }
>
> We have augmentations in process for both segment-routing and OSPFv3
Extended LSAs in progress. We will undoubtedly have others and
additional operational data.
>

Acee

Ok.

Where I think that ospf-yang needs a tweak still is in
" 15.  te-rid: Support configuration of the Traffic Engineering (TE)
    Router-ID [RFC3630], [RFC5329]. "
since RFC3630 does not contain that phrase, nor does RFC5329.

I think that the text proposed by Xufeng for teas-types handles this
issue rather well and so would propose

" 15.  te-rid: Support configuration of the Traffic Engineering (TE)
    Router-ID i.e. the Router Address described  in  Section 2.4.1 of
[RFC3630] or the Router IPv6 Address TLV described in Section 3 of
[RFC5329].

Tom Petch

> Thanks,
> Acee
>
> On 12/12/18, 7:35 AM, "tom petch" <[e-mail]> wrote:
>
>     ----- Original Message -----
>     From: "Xufeng Liu" <[e-mail]>
>     Sent: Wednesday, December 12, 2018 4:25 AM
>
>     On Tue, Dec 11, 2018 at 7:25 AM tom petch <[e-mail]>
wrote:
>
>     > ----- Original Message -----
>     > From: "Xufeng Liu" <[e-mail]>
>     > Sent: Monday, December 10, 2018 2:47 PM
>     >
>     > Hi Tom,
>     >
>     > Thanks for checking on this. Agree that we need to fix the
description
>     > text. What about the following?
>     >
>     > te-node-id:
>     >       A type representing the identifier for a node in a TE
topology.
>     > The
>     > identifier is represented as 32-bit unsigned integer in the
>     dotted-quad
>     > notation.  This attribute MAY be mapped to the Router Address
>     described
>     > in
>     > Section 2.4.1 of [RFC3630], the TE Router ID described in
Section 3 of
>     > [RFC6827], the Traffic Engineering Router ID described in
Section 4.3
>     of
>     > [RFC5305], or the TE Router ID described in Section 3.2.1 of
>     [RFC6119].
>     > The
>     > reachability of such a TE node MAY be achieved by a mechanism
such as
>     > Section 6.2 of [RFC6827].
>     >
>     > Or, would you give a suggestion?
>     >
>     > <tp>
>     >
>     > Looks good.
>     >
>     > One query I cannot answer; should
>     >   RFC5786 Advertising a Router's Local Addresses in OSPF
>     >      TE Extensions. R. Aggarwal, K. Kompella. March 2010
>     > be there as well?  On the face of it, it looks relevant and
would
>     appear
>     > to meet a need but I note its absence from ospf-yang; I do not
know
>     how
>     > widely it is implemented or used.  This RFC is updated by
RFC6827.
>
>     RFC6827 uses RFC5786, making it more generic and more complete, I
think.
>     As you said, RFC6827 has updated RFC5786, which is cited heavily
in
>     RFC6827. So, logically RFC5786 is already covered. Since RFC5786
does
>     not
>     provide a TE Router ID mapping by itself, I could not figure out a
>     concise
>     wording to cite it separately, so I felt that RFC6827 would be
more
>     relevant. Any suggestion would be appreciated.
>
>     <tp>
>
>     On reflection, leave it as it is; the text in RFC6827 is, overall,
>     clearer than RFC5786.
>
>     On an unrelated topic, te-types has references in the YANG module
to
>     RFC7823 - good - but this RFC does not appear in the References
for the
>     ID - not so good.  Having added it, you will need a reference to
it in
>     the text of the I-D lest you get an unused reference.  Common
practice
>     is to have a section preceding the module along the lines of
>     "This module imports [ ..] and references [....].  3.1 has the
imports
>     but not the references.
>
>     And it is expected to have references for imports, e.g.
>          import ietf-inet-types {
>            prefix "inet";
>            reference "RFC 6991 - Common YANG Data Types";
>
>     Tom Petch
>
>     Thanks,
>     - Xufeng
>
>     > Tom Petch
>     >
>     > Thanks,
>     > - Xufeng
>     >
>     > On Fri, Dec 7, 2018 at 12:14 PM tom petch <[e-mail]>
wrote:
>     >
>     > > ----- Original Message -----
>     > > From: "Xufeng Liu" <[e-mail]>
>     > > Subject: Re: draft-ietf-ospf-yang
>     > >
>     > > 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]."
>     > >
>     > > <tp>
>     > >
>     > > Xufeng
>     > >
>     > > Thanks for the clarification - I understand better now.
>     > >
>     > > However, I think that your proposed text is not quite right.
>     RFC5329
>     > > does not defined a TE Router ID - in fact, I think that that
concept
>     > is
>     > > alien to OSPF.  OSPF has a 32 bit number that is the Router ID
with
>     no
>     > > requirement for that to be a routable address; which is why
(IMHO)
>     > > RFC5329 defines a
>     > > Router IPv6 Address TLV
>     > > which carries a routable address (which can meet the needs of
TE).
>     > >
>     > > Likewise, RFC3630, for OSPFv2, does not have the concept of a
TE
>     > Router
>     > > ID; rather, it has a
>     > > Router Address TLV
>     > > which specifies a stable IP address (which can meet the needs
of
>     TE).
>     > >
>     > > And then there is RFC5786 which defines, for OSPF,  the
>     > > Node Attribute TLV
>     > > with sub-TLV for
>     > > Node IPv4 Local Address
>     > > Node IPv6 Local Address
>     > > allowing for multiple TE addresses for different traffic
types.
>     > >
>     > > I grant you that RFC6119 defines a
>     > >  TE Router ID
>     > > but the concept is alien to OSPF (IMHO).
>     > >
>     > > So, if you want to use the term
>     > >  TE Router ID
>     > > then I think that you will need to explain how that maps onto
the
>     > > terminology of the existing OSPF RFC.
>     > >
>     > > Tom Petch
>     > >
>     > > Thanks,
>     > > - Xufeng
>     > >
>     > > On Thu, Dec 6, 2018 at 12:38 PM Acee Lindem (acee)
<[e-mail]>
>     > > 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" <[e-mail]>
wrote:
>     > > >
>     > > >     ----- Original Message -----
>     > > >     From: <[e-mail]>
>     > > >     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:[e-mail]]
>     > > >     > Sent: Wednesday, December 05, 2018 12:14
>     > > >     > To: Acee Lindem (acee); LITKOWSKI Stephane OBS/OINIS;
>     > > [e-mail];
>     > > >     [e-mail];
>     > > [e-mail]
>     > > >     > 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)" <[e-mail]>
>     > > >     > To: "tom petch" <[e-mail]>;
>     > > >     <[e-mail]>;
>     > > >     > <[e-mail]>; <[e-mail]>;
>     > > >     > <[e-mail]>
>     > > >     > Sent: Tuesday, December 04, 2018 7:46 PM
>     > > >     >
>     > > >     > > Hi Tom,
>     > > >     > >
>     > > >     > > Let me try to explain.
>     > > >     > >
>     > > >     > > On 12/4/18, 12:44 PM, "tom petch"
<[e-mail]>
>     > 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