Nitin: I've been digging into the RBNF forms in Section 6 draft-ietf-i2rs-rib-info-model-02 based on what you indicated to mach. I would like to confirm I understand your intent of the RBNF.
1) match will augment its sequence with a type <match> ::= <ipv4-route> | <ipv6-route> | <mpls-route> | <mac-route> | <interface-route> Will be redefined as: <match> ::= <route-type> [ <ipv4-route> | <ipv6-route> | <mpls-route> | mac-route> | <interface-route>] This sequence occurs wit: 1 route-type, 1 following definition. Route-type::= <IPv4> | <IPv6> | <MPLS> | <IEEE-MAC> | <INTERFACE> (these are the values) Do I understand your values? 2) Let's take one example of your IPv4 <ipv4-route> ::= <IPv4> [<destination-ipv4-address> | <source-ipv4-address> | <destination-ipv4-address> <source-ipv4-address> <destination-ipv4-address>::=<ipv4-prefix> <ipv4-prefix> ::=<IPV4_ADDRESS> <IPV4_PREFIX_LENGTH> Are you intending to allow: destination-ipv4-address or source-ipv4-address or the combination of <destination-ipv4-address-> <source-ipv4-address>? If so, do you want a tag to identify the type of form it is? <ipv4-route> ::= <rt-form> [<destination-ipv4-address> | <source-ipv4-address> | <destination-ipv4-address> <source-ipv4-address>] <ip-form>::=<DST>|<SRC> | <DSTSRC> | < 3) Let's take the use case of matching a destination-ipv4-address: <match> ::= <IPv4> <IPv4><IPV4_ADDRESS><IPV4_PREFIX_LENGTH> I doubt you really wanted the redundant tag. This will occur for IPv6 as well. If you use a tag form that has ip-form <match>::<IPv4><DST><IPV4_ADDRESS><IPv4_PREFIX_LENGTH> 4) Would a corrections to the above be useful: Given the above you could simplify your match RBNF: <match>:: = <route-tag> <rt-form> [ipv4-route | ipv6-route | mpls-route | mac-route] ipv4-route ::= [ipv4-prefix] | [ipv4-prefix][ipv4-prefix] ipv6-route ::= [ipv6-prefix] | [ipv6-prefix][ipv6-prefix] mpls-route::= [mpls-label] | [mpls-label][mpls-label] mac-route::= [MAC_ADDRESS] | [MAC_ADDRESS][MAC_ADDRESS] These basic variables are defined in YANG Data Models and FORCES data models. You do not need to go further with the simple definitions. 5) Why did you specify differently? multicast-source-ipv4-address ::=<IPv4-Address> <IPV4_PREFIX_LENGTH> multicast-source-ipv6-address ::=<IPv6-Address><IPV6_PREFIX_LENGTH> Where you trying to express some checking that the node should have on these address? I've got similar questions on <next-hop-list>, <route-attributes> and <vendor-attributes>. I will start a different mail thread for these. Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Nitin Bahadur Sent: Friday, February 14, 2014 4:55 PM To: Mach Chen; [email protected] Cc: [email protected] Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 Hi Mach, Thanks for your comments. Please see inline below.. >General comments: >According to the recent discussion about "Multi-Headed Control", seems >there needs to define the unit of the "data" that will be changed by >the I2RS clients in this rib im document. > > >Specific Comments: >1. Section 6 ><mpls-route> ::= <MPLS> <MPLS_LABEL> ><mac-route> ::= <IEEE_MAC> ( <MAC_ADDRESS> ) > >1.1 Seems the brackets of " ( <MAC_ADDRESS> )" are redundant. Yes. We will remove them in next rev. > >1.2 What's the <MPLS> and <IEEE_MAC> stands for here? The route type? Yes..route type. > >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> > > >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. > >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). > >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. > >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. Thanks Nitin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
