Nitin: Thanks for the quick response. Just one thing to consider:
>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] [Nitin] 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 :( [Sue]: Yes, not all forms would benefit. However, MPLS does have the stack tags that we may want to save and match on. Also: the 5-tuples may be a part of matching some routes. By using rt-form, we are using the TLV format to set-up these multiple formats. Each format, would have the appropriate expectations for the appropriate address families. [Sue]: I think it provides table based code. The <ip-route-type> will need to be associated specifically with <ipv4-route> and <ipv6-route>. [Sue]: yes, it could. With the rt-form and the rib-family type, perhaps we can remove the rt-type. [snip] >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. Here's the next question - how were you planning to handle the multiple next-hops for the multicast. Did you have a plan? You will have both ECMP (unicast) multiple nexthops, and multicast replication next hops. A flag might do nicely to differentiate. We could put this on the next hop. Thanks for your review Sue _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
