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

On 05 Mar 2014, at 16:31, Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
> 
> David Lamparter <equinox@diac24.net> 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

Hmm, it is actually not that simple. It is possible to have different types of routing instances distinguished by the “rt:type” child. So it is not true that routing-instance == VRF instance.

Therefore, the correct approach is IMO this:

1. A module will be written defining the VRF type of routing instances and specifying the semantics of this kind of virtualization.

2. Where necessary, vrf-id leafs will be added to the existing module via augments.

Before this is done, alternative #3 in Martin’s list (i.e. enabling step 2 above) seems to be the best option after all.

Lada

> 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
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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