Hi Nitin, Thanks for your prompt response!
I removed parts that we agree. > > > >If so, why not apply this to the <ipv4-prefix> and <ipv6-prefix> as > >well ,hence <ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_ADDRESS_LENGTH> > >would be <ipv4-prefix> ::= <IPv4> <IPV4_ADDRESS> > <IPV4_ADDRESS_LENGTH>, > >and <ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_ADDRESS_LENGTH> would be > ><ipv6-prefix> ::= <IPv6> <IPV6_ADDRESS> <IPV6_ADDRESS_LENGTH> > > I think I know what you mean. What might be more appropriate would be: > > <ipv4-route> ::= <IPv4> (<destination-ipv4-address> | <source-ipv4-address> | > (<destination-ipv4-address> > <source-ipv4-address>)) > > Or the other way to model this would be: > > > <match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> | > <mac-route> | <interface-route>) <route-type> ::= > <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE> I am OK with either way. > > > > > >2. Section 6 > ><rib-family> ::= <IPV4_RIB_FAMILY> | <IPV6_RIB_FAMILY> | > > <MPLS_RIB_FAMILY> | <IEEE_MAC_RIB_FAMILY>, > > > >and > > > ><match> ::= <ipv4-route> | <ipv6-route> | <mpls-route> | > > <mac-route> | <interface-route> There are four rib > >families defined, but there are five types route, so which rib family > >does the interface-route belong to? Seems there needs a > ><INTERFACE_RIB_FAMILY>. > > An interface is part of a routing-instance <routing-instance> ::= > <INSTANCE_NAME> > [<interface-list>] <rib-list> [<ROUTER_ID>] > > The purpose of a RIB family is essentially to identify what protocol > treatment to > give to a packet. For example, for an IPv4 packet, you would do a TTL check. > For > an interface-route, there is no such behavior. An IPv4 route can be associated > with any interface in the <interface-list> above. > Interface-route is more of a container (match) for all packets coming in on an > interface. The network-device can choose to do DPI on the packet and run > checks before it processes interface-route matching packets, or it can just > choose > to do what the interface-route says (match all packet coming in interface-A > and > send them out via interface-B). > > > So in summary, I don¹t see a real need for INTERFACE_RIB_FAMILY. OK. > > > > > >3. Section 6 > ><route> ::= <match> <nexthop-list> > > [<route-attributes>] > > [<route-vendor-attributes>] > > > >When a route was installed in the RIB, there should be an indication to > >identify from which protocols (e.g., ISIS, OSPF, BGP, I2RS, CLI etc.) > >the route is. So there may need a <Origin> attribute. > >Maybe similar like this: > ><Origin> ::= <RIP> | <OSPF> | <ISIS> | <BGP> | <LDP> | <RSVP-TE> | > ><CLI> > >| <I2RS> > > > >How do you think? > > Yes, there ³could² be such an optional attribute. What we need to think more > towards is, is just the protocol-type sufficient or do you need other things > as well, > like protocol peer address (just thinking aloud). At present, protocol-type is the straightforward one, I am not sure the protocol peer address is needed in the rib, there needs a use case to justify it. Another attribute may be needed is the I2RS client identifier, since there will be multiple clients that may install route into the rib. > > > > >4. Section 6 > ><tunnel-type> ::= <IP> | <MPLS> | <GRE> | <VxLAN> | <NVGRE> > > > >Should the <IP> be more specific to <IPv4> and <IPv6>? What does the > ><IP> really intend for? UDP, TCP? And there may be other tunnel, e.g., l2tp. > > Makes sense to have IPv4 and IPv6 called out separately. The IPv4/v6 is > basically > for IP-in-IP tunnels. And yes, there could be other tunnels like L2TP, etc. I > guess > we don¹t want to create an exhaustive list of tunnels in the info model, but > rather leave it to the data model and data-model extensions. We¹ll split the > v4/v6 stuff in next rev. OK. > > > > > >5. Section 7.1 > > > >AS-data information and AS length comparison are BGP related stuff, > >this should be transparent to RIB manager. I am not sure whether this > >belongs to Rib info model. > > This has been removed in the latest version. OK. Thanks Mach > > Thanks > Nitin > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
