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

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

Independent of the hierarchy, I think an interface should be associated
with one and only routing-instance. I know of no implementation that
allows this (including the use case of separate instances for IPv4 and
IPv6). 

Thanks,
Acee 

On 2/13/15, 12:45 PM, "Acee Lindem (acee)" <[e-mail]> wrote:

>
>
>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
>
>_______________________________________________
>Rtg-yang-coord mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord