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

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

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. 

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
    Subject: Re: draft-ietf-ospf-yang
    
    
    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
    > > >     > >
    > > >     > >
    > > >     > >
    > > >     > >
    > > >     >
    > > >     >
    > > >     >
    > > >
    > > >
    > >
    >
    ________________________________________________________________________
    > > >     _________________________________________________
    > > >     >
    > > >     > 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.
    > > >     >
    > > >     >
    > > >
    > > >
    > > >
    > > >
    > >
    > >
    >
    >