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

[David Lamparter <[e-mail]>]

(comments below)

On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote:
> David Lamparter <[e-mail]> 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)
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