Re: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections

On 05 Mar 2014, at 17:01, David Lamparter <equinox@diac24.net> wrote:

> (comments below)
> 
> On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote:
>> David Lamparter <equinox@diac24.net> wrote:
>>> The original question was, how the configured device chooses a "VPN"
>>> for
>>> either incoming or outgoing connections.  This referred to VRF
>>> instances.  In particular, for the very simplest case where this
>>> matters, there are devices that have out of band management ports and
>>> treat those as a VRF.  So, both for listening and for connecting, the
>>> device needs to choose between "VR-Default" and "VR-Mgmt" (actual
>>> names,
>>> guess the vendor.)  It could even listen in both VRFs, to be
>>> manageable
>>> inband (normal ops maybe?) and out of band (network in flames?).
>>> 
>>> Even though this was raised on the server config model, this is a
>>> rather
>>> generic problem.  E.g. specifying a NTP or Syslog server has the same
>>> issue.  (Cc' from netconf to netmod due to this.)
>> 
>> If I understand this correctly, the proposal is to include a reference
>> to a routing-instance (rt:routing-instance-ref) in all cases where we
>> currently have an ip-address (or host) and a port, since the
>> combination of ip-adress and port is not guaranteed to be unique, on
>> systems with multiple routing instances.
> 
> Indeed, with the caveat that this also applies to listening ports (which
> are specified just the same, just noting it so this doesn't get lost.)
> 
>>  leaf address          { type inet:ip-address; }
>>  leaf port             { type inet:port-number; }
>>  leaf routing-instance { type rt:routing-instance-ref; }
>> 
>> 
>> The existsing data models (specifically ietf-system) are designed in a
>> way that vendors can augment there own definition of routing-instance
>> or vrf.  (However, I noticed that ietf-snmp is not).
>> 
>> The question is if the IETF models should include a standardized way
>> to handle this.  I can see three alternatives:
>> 
>>  1)  Do nothing.  I.e., assume ip/port is unique.
>> 
>>  2)  In all our data models, always make sure we add an (optional)
>>      reference to a routing-instance, whenever we have a ip/port for
>>      inbound/outbound traffic.
>> 
>>  3)  Do not add the routing-instance references, but design our data
>>      models so that vendors can augment with this if they have to.
> 
> It seems that 1) would imply a mixture of not having support for this
> and case 3) in places where we already allow extensions, and I'd claim
> that this inconsistency is undesirable.
> 
> I would however argue for option 2), based on the fact that routing-cfg
> does have routing instances in a standardised way, and I don't see the
> point in each vendor defining a distinct extension to add this
> reference.  Essentially, I would say that if there's a problem with 2)

As Juergen already pointed out in his reply, a standard model can be written for this purpose, too.

Lada

> here, there's also a problem with routing instances in routing-cfg,
> which in turn means we fix that or we're headed for neverland on the
> express train.
> 
> 
> Cheers,
> 
> 
> -David
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C