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

From: David Lamparter <[email-masked]>
Date: Mon, 3 Mar 2014 15:00:40 +0100

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.)

NB: I haven't followed this topic, there might be some simple answer
that I'm not aware of.

-David

(Sorry for the garbled jump to the mic, this wasn't on my radar, I was
only able to parse the meaning of "VPN".)

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Mar 2014 16:31:54 +0000 (GMT)

Hi,

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Mar 2014 17:46:49 +0100

>       models so that vendors can augment with this if they have to.

My preference is 3) unless there is documented IETF agreement
that addressing needs to include a routing instance (e.g., a
standards-track RFC). My understanding is that 3) also allows
IETF augmentations, not only vendor augmentations.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 5 Mar 2014 16:51:08 +0000

>      models so that vendors can augment with this if they have to.

My preference is #3.

Lada

> 
> 
> /martin
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: David Lamparter <[email-masked]>
Date: Wed, 5 Mar 2014 18:01:03 +0100

(comments below)

> 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.)

>       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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 5 Mar 2014 17:15:23 +0000

> 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

---

From: David Lamparter <[email-masked]>
Date: Wed, 5 Mar 2014 18:15:13 +0100

> IETF augmentations, not only vendor augmentations.

I've made this as an assumption in my previous answer, but didn't
explicitly mention it:  I believe having support for routing instances
in routing-cfg and having a reference in addressing share the same
reasoning:  there are configurable systems that contain more than one
VRF / IP stack / routing domain / whatever you call it.  And as such,
just like you can't add a static route without saying which of these
instances you want to insert it in, it's underspecified from where you
want to establish your syslog connection if you don't specify the IP
stack instance to be used.

Yes, there might be a default instance for management.  But I believe
the rather widespread case of a box with in-band + out-of-band
management rectifies always having this reference.  We're not talking
about enterprise routers here, this is 400€ small-business COTS
switches.

Are there reasons for modeling routing instances in routing-cfg that
don't apply here?

NB: it might be an acceptable solution to fix this in a separate draft
for existing extensible cases, so we don't need to reroll things.
However, for future models, I don't think we want to create a
VRF-for-this VRF-for-that extra spec each single time?

-David

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 5 Mar 2014 17:31:47 +0000

> Are there reasons for modeling routing instances in routing-cfg that

It should probably be spelled out somewhere, but in many cases there will only be a single routing instance, so it is bound to be the default to be used for all routing.
 
> VRF-for-this VRF-for-that extra spec each single time?

I see your point, a separate draft can only define augments for the existing cases. Then #2 might be indeed better, perhaps using a feature like “multiple-routing-instances”.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Mar 2014 09:12:41 +0000

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Mar 2014 21:14:25 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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.
> 
> 1. A module will be written defining the VRF type of routing instances and
> specifying the semantics of this kind of virtualization.
> 
> Before this is done, alternative #3 in Martin’s list (i.e. enabling step 2
> above) seems to be the best option after all.

I fully agree with this.  Depending on timing, 2 above can be done
with augmentation or by revising the existing modules.

... but you write "a module will be written".  It won't write itself.
Has anyone volunteered to work on this?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Mar 2014 23:03:04 +0000

> Has anyone volunteered to work on this?

It should be a knowledgeable person who is interested in having the VRF stuff implemented.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Mar 2014 17:39:42 +0000

> It should be a knowledgeable person who is interested in having the VRF

Not me, but I did verify with other routing experts that being able to do
this is necessary...

Any volunteers?

K.

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 8 Mar 2014 08:57:15 +0100

On 07 Mar 2014, at 18:39, Kent Watsen <[email-masked]> wrote:

> this is necessary…

I am prepared to help them integrate this work into the core routing model.

Lada