I guess in the L3VPN use case, both the IPv4 and IPv6 VPNs are for the same
customer (since the interface only goes to one place).
I’ve been thinking about this for much of the morning and I see, at least, the
following options:
1. Move the reference(s) to routing-instance to
“/if:interfaces/if:interface/ip:ipv4” and
“/if:interfaces/if:interface/ip:ipv6”.
2. Keep the reference at the “/if:interface/if:interface/“ level but
make it a container with a more complex structure including the overall
reference and feature enabled override references for specific purposes (L2,
IPv6, IPv4, etc).
3. Others?
I like #2 since it is optimized towards the most common use case.
With respect to encapsulation, I don’t understand how they could be different
for different AFs unless they are, in fact, different RFC 7223 interfaces. Am I
missing something?
Thanks,
Acee
From: Rob Shakir <r...@rob.sh<mailto:r...@rob.sh>>
Date: Wednesday, October 21, 2015 at 9:58 AM
To: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Routing WG
<rt...@ietf.org<mailto:rt...@ietf.org>>, "i...@ietf.org<mailto:i...@ietf.org>"
<i...@ietf.org<mailto:i...@ietf.org>>, NETMOD WG
<netmod@ietf.org<mailto:netmod@ietf.org>>, Routing YANG
<rtg-yang-co...@ietf.org<mailto:rtg-yang-co...@ietf.org>>
Subject: Re: [netmod] rib-data-model and routing-cfg
On 21 October 2015 at 07:52:43, Ladislav Lhotka
(lho...@nic.cz<mailto:lho...@nic.cz>) wrote:
One option would be to create two virtual interfaces - one for IPv4 VPN and
another for IPv6 VPN, and define routing-instance and addresses separately for
each.
This is only workable if an implementation must support two virtual interfaces
that have the same underlying encapsulation (i.e.., they are simply logically
separating IPv4 and IPv6), in some implementations, this isn’t the case, and
the virtual interfaces must have different encapsulations.
In openconfig-interfaces, each sub-interface is associated with a single VLAN,
so in this case, we would need the network-instance to be specified on a per
address-family basis there. There is nothing to stop one having a single leaf
at the sub-interface or interface level that is inherited by the other
constructs - this is something that I have been considering based on work on
the network-instance model that we recently published.
r.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
