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)" <[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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
