Re: [Rtg-yang-coord] issue :R03: assignment of interfaces to routing instances

[Ladislav Lhotka <[e-mail]>]

"Acee Lindem (acee)" <[e-mail]> writes:

> On 2/13/15, 5:25 AM, "Ladislav Lhotka" <[e-mail]> wrote:
>
>>"Acee Lindem (acee)" <[e-mail]> 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

Yes, here is an example:

https://www.juniper.net/documentation/en_US/junos14.2/topics/example/routing-instance-interface-settings-configuring-junos-nm.html

Lada

> 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"
>>> <[e-mail]> 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: [phone]         Campus Ring 1, 28759 Bremen, Germany
>>>>Fax:   [phone]         <http://www.jacobs-university.de/>
>>>
>>
>>-- 
>>Ladislav Lhotka, CZ.NIC Labs
>>PGP Key ID: E74E8C0C
>

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