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