"Acee Lindem (acee)" <[email protected]> writes:
> Independent of the hierarchy, I think an interface should be associated
> with one and only routing-instance. I know of no implementation that
We've been there, too. In revision -02, we had this definition ("router"
later became "routing-instance"):
list router {
key "name";
unique "interfaces/interface/name";
...
}
The role of the "unique" statement was to restrict the assignment of
interfaces exactly as you write.
But then we had a discussion in the NETMOD mailing list about whether
such a unique statement is legal or not:
http://www.ietf.org/mail-archive/web/netmod/current/msg06386.html
While I still think there is nothing wrong with that unique statement,
it was eventually removed for the "ietf-routing" module.
> allows this (including the use case of separate instances for IPv4 and
> IPv6).
This is not necessarily true. In my data model for the BIRD routing
daemon
(https://gitlab.labs.nic.cz/labs/yang-tools/tree/master/data-models/bird)
I am using special types of routing-instances "bird-ipv4" and
"bird-ipv6", and the same interface can be in both instances. This is
because BIRD has to be compiled separately with support for IPv4 and
IPv6, and each routing-instance then corresponds to one BIRD process.
Yes, such an implementation is somewhat peculiar and needn't serve as a
model. On the other hand, I don't see any reason why overlapping
interface assignments should be made illegal for *all* types of routing
instances.
I assume the data model for routing instances of the type "VRF" will
state that assignments of interfaces to routing instances have to be
disjoint, and the draft explicitly states such an additional constraint
is allowed (last paragraph in sec. 5.1). Isn't this sufficient?
Lada
>
> Thanks,
> Acee
>
> On 2/13/15, 12:45 PM, "Acee Lindem (acee)" <[email protected]> wrote:
>
>>
>>
>>On 2/13/15, 5:25 AM, "Ladislav Lhotka" <[email protected]> wrote:
>>
>>>"Acee Lindem (acee)" <[email protected]> writes:
>>>
>>>> I believe the fact that we are having trouble resolving this is that
>>>>the
>>>> model is wrong. I would propose the following:
>>>
>>>I don't agree the model is wrong. In fact, I belive in Junos CLI it is
>>>done exactly the same way, e.g.
>>>
>>> set interface fe-0/0/2 unit 0 family inet address 6.6.6.5/24
>>>
>>> set routing-instances blue-vr interface fe-0/0/2.0
>>>
>>>(IP address is configured in the interface subtree, and an interface is
>>>assigned to a VRF in the routing-instance subtree).
>>>
>>>I believe the troubles we are having are due to the different logic in
>>>the CLIs of the two major routing platforms.
>>
>>Does it show up as a separate list in the JUNOS gated-like configuration
>>hierarchy? If they do configure the IPv4/IPv6 addresses disjoint from the
>>routing -instance instances imply the corresponding IPv4/IPv6 address
>>space and the RIBs, I still don’t like the inconsistency.
>>
>>The previous product I worked on, IPOS, had the interfaces in
>>routing-instance but the routing-instance interface included all the layer
>>3 definition including the IP/IPv6 addresses (i.e., the RFC 7277
>>definitions).
>>
>>Thanks,
>>Acee
>>
>>
>>
>>
>>
>>
>>>
>>>Lada
>>>
>>>>
>>>> 1. Remove the interface list completely from rtf-cfg configuration.
>>>> 2. Augment the RFC 7223 to include a reference to a
>>>>routing-instance.
>>>> An interface should be part of one and only one routing-instance.
>>>> 3. Provide a list of interfaces in the operational state in the
>>>>rtg-cfg
>>>> model.
>>>>
>>>> One reason I'm proposing this change is that I believe a
>>>>routing-instance
>>>> implies an IPv4/IPv6 address space and the interfaces list MUST NOT be
>>>> disjoint from the assigned addresses (refer to RFC 7277). If you want
>>>>to
>>>> have a list of interfaces in the routing-instance, you should deprecate
>>>> RFC 7277 or, at least, say that it only applies to the default
>>>>instance.
>>>>
>>>> In all fairness, Lada disagrees with me on this point and wants the
>>>> flexibility of associating an interface with multiple
>>>>routing-instances.
>>>> Additionally, he feels that the list inside the routing-instance will
>>>> facilitate better interface selection checking. I don¹t see the latter
>>>>as
>>>> an issue as the same checking could be applied when an attempt is made
>>>>to
>>>> augment the RFC 7223 interface.
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>>
>>>>
>>>> On 1/14/15, 12:46 PM, "Juergen Schoenwaelder"
>>>> <[email protected]> wrote:
>>>>
>>>>>On Wed, Jan 14, 2015 at 04:43:29PM +0000, Xufeng Liu wrote:
>>>>>> Hi Andy,
>>>>>>
>>>>>> The concatenated string format is actually what we plan to do.
>>>>>>However,
>>>>>>to me, it is more like a hack than an engineered solution. The model
>>>>>>fails to capture such a relationship properly.
>>>>>>
>>>>>
>>>>>If your interface names are no unique, I would assume that you will
>>>>>face other issues as well. For example, one may use an interface name
>>>>>to disambiguate link-local addresses. I am not sure how that works if
>>>>>your interface name is not unique.
>>>>>
>>>>>/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/>
>>>>
>>>
>>>--
>>>Ladislav Lhotka, CZ.NIC Labs
>>>PGP Key ID: E74E8C0C
>>
>>_______________________________________________
>>Rtg-yang-coord mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
