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

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

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