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

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

Hi Lada, 

Interesting - I see that in Junos the addresses are configured disjoint
from the assignment of the address to a routing-instance.

https://www.safaribooksonline.com/library/view/junos-enterprise-routing/978
1449309633/ch04s04.html

Has this caused confusion?

Thanks,
Acee 

On 2/14/15, 5:46 AM, "Ladislav Lhotka" <[e-mail]> wrote:

>"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/routi
>ng-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