Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts

From: Alan Davey <[email-masked]>
Date: Wed, 11 May 2016 16:40:25 +0000

Hi Derek

A question about the key for OSPF interfaces in the Yang draft.  Please let me know what you think.

The background is that the Management Information Base definitions define indices for OSPF interfaces as follows.

-          For OSPFv2, RFC 4750 defines the index as ospfIfIpAddress, ospfAddressLessIf.

-          For OSPFv3, RFC 5643 defines the index as ospfv3IfIndex, ospfv3IfInstId.

However, in the OSPF Yang draft, the key is defined as "interface", which I believe is a name of the interface.

How does "interface" map to the indices defined in RFCs 4750 and 5643?

Thanks
Alan

---

From: t.petch <[email-masked]>
Date: Thu, 12 May 2016 18:41:06 +0100

----- Original Message -----
From: "Alan Davey" <[email-masked]>
To: "Derek Man-Kit Yeung (myeung)" <[email-masked]>;
<[email-masked]>
Cc: "OSPF WG List" <[email-masked]>
Sent: Wednesday, May 11, 2016 5:40 PM

Hi Derek

A question about the key for OSPF interfaces in the Yang draft.  Please
let me know what you think.

The background is that the Management Information Base definitions
define indices for OSPF interfaces as follows.

-          For OSPFv2, RFC 4750 defines the index as ospfIfIpAddress,
ospfAddressLessIf.

-          For OSPFv3, RFC 5643 defines the index as ospfv3IfIndex,
ospfv3IfInstId.

However, in the OSPF Yang draft, the key is defined as "interface",
which I believe is a name of the interface.

<tp>

It doesn't (IMHO).  You have two lists of interfaces in this I-D

container interfaces { description "All interfaces."; list interface {
key "interface";
description "List of OSPF interfaces.";

container interfaces { description "All interfaces in the area.";  list
interface { key "interface";
description "List of OSPF interfaces.";

both keyed on 'interface' (which is two separate lists so two separate
'interface' leaf, different sets of key objects.).

Both are defined as

     type if:interface-ref;

and the if: harks back to
     import ietf-interfaces {prefix "if";
and ietf-interfaces is in RFC7223 where interface-ref is defined as
"   An interface is identified by its name, which is unique within the
   server.  This property is captured in the "interface-ref" and
   "interface-state-ref" typedefs, which other YANG modules SHOULD use
   when they need to reference a configured interface or operationally
   used interface, respectively."

So both lists are keyed on a name which is unique within the server and
can be anything, such as 'lan0' or 'fast-ethernet-23/7' or
'hotplug23/6/15' or... It all depends; names may be dictated by the
hardware with no choice, or they may be dictated by the software to
compliant hardware or ...

Underlying this is the thought that we have no good definition of an
interface, one that works across all protocols and other aspects of a
configuration; an interface is like a blob of jelly and pinning it down
to be a name is about as good a grasp of it as we will get (IMO).

Tom Petch

Thanks
Alan

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 May 2016 14:02:27 +0000

Hi Tom, 

On 5/12/16, 1:41 PM, "OSPF on behalf of t.petch" <[email-masked] on

>'interface' leaf, different sets of key objects.).

These are basically the same lists - one is for operational state and the
other is for configuration.

>to be a name is about as good a grasp of it as we will get (IMO).

Agreed. 

Thanks,
Acee 

>
>Tom Petch
>
>Thanks
>Alan
>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: Alan Davey <[email-masked]>
Date: Fri, 13 May 2016 14:37:26 +0000

Hi Tom and Acee

Thank you for getting back to me.  I understand that an "interface" is identified by its name.  My doubt is about how OSPFv2 configuration defined for an "interface" is mapped to an internal OSPFv2 interface object that is indexed on IP address (as per RFC 4750).  Perhaps you could let me know what you think.

In more detail, consider the case where one interface is assigned multiple IP addresses.  The OSPFv2 protocol considers these to be separate networks (as per RFC 2328, section 1.2, for example).  If the OSPFv2 configuration is defined per interface, is that configuration applied to all of the separate OSPFv2 interfaces or to one of them?  If to one of them then how is that one selected?

Regards
Alan

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: 13 May 2016 15:02
To: t.petch <[email-masked]>; Alan Davey <[email-masked]>; Derek Man-Kit Yeung (myeung) <[email-masked]>; [email-masked]
Cc: OSPF WG List <[email-masked]>
Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts

Hi Tom, 

On 5/12/16, 1:41 PM, "OSPF on behalf of t.petch" <[email-masked] on behalf of [email-masked]> wrote:

>key "interface"; description "List of OSPF interfaces.";
>
>interface { key "interface"; description "List of OSPF interfaces.";
>

These are basically the same lists - one is for operational state and the other is for configuration.

>     import ietf-interfaces {prefix "if"; and ietf-interfaces is in 
>RFC7223 where interface-ref is defined as

Agreed. 

Thanks,
Acee

---

From: t.petch <[email-masked]>
Date: Fri, 13 May 2016 17:31:05 +0100

----- Original Message -----
From: "Alan Davey" <[email-masked]>
Sent: Friday, May 13, 2016 3:37 PM

> Hi Tom and Acee
>
> Thank you for getting back to me.  I understand that an "interface" is
identified by its name.  My doubt is about how OSPFv2 configuration
defined for an "interface" is mapped to an internal OSPFv2 interface
object that is indexed on IP address (as per RFC 4750).  Perhaps you
could let me know what you think.
>
> In more detail, consider the case where one interface is assigned
multiple IP addresses.  The OSPFv2 protocol considers these to be
separate networks (as per RFC 2328, section 1.2, for example).  If the
OSPFv2 configuration is defined per interface, is that configuration
applied to all of the separate OSPFv2 interfaces or to one of them?  If
to one of them then how is that one selected?

On your first point, RFC4750 defines the appearance of a box to the
outside world, as all MIB modules do; how this is implemented internally
is an implementation decision so internally, there may not be the
concept of an object let alone one that is keyed on IP address!
Equally, a YANG module is a contract between device and NMS; it is the
appearance that matters, the internal implementaton can be quite
different.  YANG requires that interfaces have names but that allows a
lot of choice.

The YANG OSPF module maps configuration information to an interface,
identified by name.  The YANG ip module augments the interface with a
list of IP addresses.  An implementor can choose to have an interface
with one IP address, many interfaces each with one address, many with
many and so on, may be constrained by the protocols in use.

My experience of multiple IPv4 addresses is using them to overcome the
limitations of subnet masks with one as primary, the others as
secondary; I cannot recall configuring OSPF on more than one, the
primary, in which case OSPF configuration would only apply to that.  I
suspect that multicast considerations would make it impossible to run
OSPF over a secondary address but I could be wrong.

The YANG modules allow an implementor to treat each IP address as a
separate named interface, one address per interface, which would allow
each to run OSPF and be configured separately for that.  I do not know
if anyone will implement this - ask your favourite supplier of
hardware:-)

This issue, of multiple addresses on an interface, was discussed on the
netmod list in 2011/2012.

Tom Petch

> To: t.petch <[email-masked]>; Alan Davey
<[email-masked]>; Derek Man-Kit Yeung (myeung)
<[email-masked]>; [email-masked]
> On 5/12/16, 1:41 PM, "OSPF on behalf of t.petch"

---

From: Alan Davey <[email-masked]>
Date: Mon, 16 May 2016 08:44:32 +0000

Hi Tom

Thanks for your quick response.  I just want to check that I understand your email.  Please let me know if the following is correct or not.

-  You expect that the NMS would identify an interface by name in all cases of protocol configuration, where there is flexibility on what the "interface" represents.

-  There will only ever be one primary IP address assigned to an interface (or zero in the case of unnumbered point to point interfaces).

-  There is a set of zero or more secondary IP addresses that may be assigned to the interface.

-  Only the primary address (or unnumbered interface) would ever have OSPF configuration associated with it.  Secondary addresses never have OSPF configuration associated.  (As an aside, multicast considerations do not preclude running OSPF using a secondary address.)

-  I assume that in the case of a non-empty set of secondary addresses, the secondary addresses should be advertised by the OSPF protocol.  Is this true?

Regards
Alan

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: 13 May 2016 17:31
To: Alan Davey <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Derek Man-Kit Yeung (myeung) <[email-masked]>; [email-masked]
Cc: OSPF WG List <[email-masked]>
Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts

----- Original Message -----
From: "Alan Davey" <[email-masked]>
Sent: Friday, May 13, 2016 3:37 PM

> Thank you for getting back to me.  I understand that an "interface" is
identified by its name.  My doubt is about how OSPFv2 configuration defined for an "interface" is mapped to an internal OSPFv2 interface object that is indexed on IP address (as per RFC 4750).  Perhaps you could let me know what you think.
> In more detail, consider the case where one interface is assigned
multiple IP addresses.  The OSPFv2 protocol considers these to be separate networks (as per RFC 2328, section 1.2, for example).  If the
OSPFv2 configuration is defined per interface, is that configuration applied to all of the separate OSPFv2 interfaces or to one of them?  If to one of them then how is that one selected?

On your first point, RFC4750 defines the appearance of a box to the outside world, as all MIB modules do; how this is implemented internally is an implementation decision so internally, there may not be the concept of an object let alone one that is keyed on IP address!
Equally, a YANG module is a contract between device and NMS; it is the appearance that matters, the internal implementaton can be quite different.  YANG requires that interfaces have names but that allows a lot of choice.

The YANG OSPF module maps configuration information to an interface, identified by name.  The YANG ip module augments the interface with a list of IP addresses.  An implementor can choose to have an interface with one IP address, many interfaces each with one address, many with many and so on, may be constrained by the protocols in use.

My experience of multiple IPv4 addresses is using them to overcome the limitations of subnet masks with one as primary, the others as secondary; I cannot recall configuring OSPF on more than one, the primary, in which case OSPF configuration would only apply to that.  I suspect that multicast considerations would make it impossible to run OSPF over a secondary address but I could be wrong.

The YANG modules allow an implementor to treat each IP address as a separate named interface, one address per interface, which would allow each to run OSPF and be configured separately for that.  I do not know if anyone will implement this - ask your favourite supplier of
hardware:-)

This issue, of multiple addresses on an interface, was discussed on the netmod list in 2011/2012.

Tom Petch

> To: t.petch <[email-masked]>; Alan Davey
<[email-masked]>; Derek Man-Kit Yeung (myeung) <[email-masked]>; [email-masked]

---

From: t.petch <[email-masked]>
Date: Tue, 17 May 2016 10:42:58 +0100

----- Original Message -----
From: "Alan Davey" <[email-masked]>
To: "t.petch" <[email-masked]>; "Acee Lindem (acee)"
<[email-masked]>; "Derek Man-Kit Yeung (myeung)" <[email-masked]>;
<[email-masked]>
Cc: "OSPF WG List" <[email-masked]>
Sent: Monday, May 16, 2016 9:44 AM

> Hi Tom
>
> Thanks for your quick response.  I just want to check that I
understand your email.  Please let me know if the following is correct
or not.
>
> -  You expect that the NMS would identify an interface by name in all
cases of protocol configuration, where there is flexibility on what the
"interface" represents.
>
> -  There will only ever be one primary IP address assigned to an
interface (or zero in the case of unnumbered point to point interfaces).
> -  Only the primary address (or unnumbered interface) would ever have
OSPF configuration associated with it.  Secondary addresses never have
OSPF configuration associated.  (As an aside, multicast considerations
do not preclude running OSPF using a secondary address.)
>
> -  I assume that in the case of a non-empty set of secondary
addresses, the secondary addresses should be advertised by the OSPF
protocol.  Is this true?

My context is IPv4 (despite my erroneous reference to multicast:-); with
IPv6, interfaces are expected to have multiple IP addresses and so
applications must be prepared for that.  With IPv4, the concept came
late in the day which is why I am uncertain about how much support there
is thereof.

Using a NMS with NETCONF and the IETF YANG models, then the protocol/DDL
identifies the interface, whatever that may be, physical, logical (FR
VC, MPLS LSP, ...) by name; the YANG list is keyed by 'name' which is a
change in approach from that of the MIB module.  How the NMS presents
that to the user is up to the NMS (it could be - I don't know - that an
NMS chooses to use IPv4 addresses because that is what users are
familiar with).

Secondary addresses I saw first with one router manufacturer and then
later with others; I would expect most to support them.  The
implementations I have seen have only one primary.  I have always seen
secondary addresses as an unsatisfactory solution to addressing issues
and while they were needed at the time, I would like to think that their
use has diminished since.  I would look askance at a design that uses
them in this day and age.  Doubtless they are still around but how
widespread they are, I don't know.  (I was active in getting them
included in the YANG model which I do not think that all those involved
were).

The configuration of OSPF may have an option to advertise or to suppress
the advertisement of secondary addresses in the LSA.

Whether or not a secondary address can be used for other purposes in
OSPF, such as DR or BDR, I am unsure; something at the back of my mind
says there is an issue with the use of broadcast by a DR but I cannot
track down a reference to that.  With the proposed YANG models - if-cfg,
ip-cfg, ospf - it is feasible to configure a secondary interface in the
same way as a primary one, should the device support that.

Tom Petch

> From: t.petch [mailto:[email-masked]]

<snip>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 May 2016 12:04:03 +0000

<Speaking as a member of the OSPF YANG Design Team>
What we did with the OSPF YANG model was use interface as the key to list
even though OSPFv2 allows configuration by IP subnet. This is consistent
with both OSPFv3 and the interface YANG models in RFC 7223 and RFC 7277.

Thanks,
Acee