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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Alan Davey" <[e-mail]>
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

> Regards
> Alan
>
>
> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[e-mail]]
> Sent: 13 May 2016 15:02
> To: t.petch <[e-mail]>; Alan Davey
<[e-mail]>; Derek Man-Kit Yeung (myeung)
<[e-mail]>; [e-mail]
> Cc: OSPF WG List <[e-mail]>
> 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"
<[e-mail] on behalf of [e-mail]> wrote:
>
> >----- Original Message -----
> >From: "Alan Davey" <[e-mail]>
> >To: "Derek Man-Kit Yeung (myeung)" <[e-mail]>;
> ><[e-mail]>
> >Cc: "OSPF WG List" <[e-mail]>
> >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.
> >
> >How does "interface" map to the indices defined in RFCs 4750 and
5643?
> >
> ><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.).
>
> These are basically the same lists - one is for operational state and
the other is for configuration.
>
>
> >
> >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).
>
> Agreed.
>
> Thanks,
> Acee
>
>
>
> >
> >Tom Petch
> >
> >Thanks
> >Alan
> >
> >_______________________________________________
> >OSPF mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ospf
>
>