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

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

----- Original Message -----
From: "Alan Davey" <[e-mail]>
To: "t.petch" <[e-mail]>; "Acee Lindem (acee)"
<[e-mail]>; "Derek Man-Kit Yeung (myeung)" <[e-mail]>;
<[e-mail]>
Cc: "OSPF WG List" <[e-mail]>
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).
>
> -  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?

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

> Regards
> Alan
>
>
> -----Original Message-----
> From: t.petch [mailto:[e-mail]]
> Sent: 13 May 2016 17:31

<snip>