Hi Sue, > >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?
Correct. > >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> | < Yes, I am intending to allow all 3 possibilities. A tag is needed. <ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC> (this will apply to IPv4 and IPv6) > > >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] The <rt-form> is not needed for mpls and mac routes.since MPLS has no concept of SRC or DEST. So that simplification will actually not help :( The <ip-route-type> will need to be associated specifically with <ipv4-route> and <ipv6-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? Thanks for catching this. They have no reference in the -02 version. They are a remnant of -00 of the draft. After the grammar was modified in -01, they should have been deleted. > I've got similar questions on <next-hop-list>, <route-attributes> >and <vendor-attributes>. I will start a different mail thread for these. Looking forward Thanks Nitin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
