Hi Sue, > > > >>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 main issue is that the grammar will not be deterministic. In other words, one needs a way to specify that <route-tag-1> <rt-form-A> is valid and <route-tag-1> <rt-form-B> is NOT valid. > >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] Rib-family-type and route-type are kind of the same thing. I need to think if there is a case where they can be different... > >>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, Unicast multiple next hops are covered in Section 7.2.3. > and multicast replication next hops. Section 7.3 talks about multicast replication (and refers to Section 7.2.2). > A flag might do nicely to differentiate. >We could put this on the next hop. LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to indicate ECMP/load-balancing. Thanks Nitin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
