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

[Martin Bjorklund <[e-mail]>]

Hi,

David Lamparter <[e-mail]> wrote:
> Hi,
> 
> 
> (this is the mail version of the somewhat garbled comment on the mic)
> 
> 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.

  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.


/martin