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

["Acee Lindem (acee)" <[e-mail]>]

Hi Tom, 

On 12/14/18, 12:44 PM, "tom petch" <[e-mail]> wrote:

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

Yes - I will add this. 

Thanks,
Acee
    
    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