Hi Sue, From: Susan Hares <[email protected]> Date: Sunday, April 20, 2014 at 2:31 PM To: <[email protected]> Cc: 'Jeffrey Haas' <[email protected]>, <[email protected]>, Alia Atlas <[email protected]> Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02
> Nitin, Ron, Kini, Jan: > > 1) Is Section 7 of your document normative or informative? > > Section 7 is informative. > 2) Your grammar seems wordy/inconsistent in the repetition of the next > hop below > > > Your RIB grammar on page 17 states: > > > <nexthop-list> ::= <special-nexthop> | > ((nexthop-list-member>) | > (<nexthop-list-member> | <nexthop-list>)) > > <nexthop-list-member> ::= (<nexthop-chain> | > <nexthop-chain-identifier>) > > [<nexthop-list-member-attributes>] > > <nexthop-chain>::= (<nexthop> ) > > Questions: Why do you have nexthop-list-member listed twice? Why list > <nexthop-list> twice? Is this readability or technical matter? > > > Why not: > <nexthop-list>::= ((<special-nexthop> | (nexthop-list-member) ) Good question. It¹s a technical matter. The above (and below) format is needed to satisfy certain types of nexthops. I will list each of them. ([<nexthop-list-member> ... ] <nexthop-list> )) ===> recursion. What you get from this is a way to perform the following actions on a given packet: * RECEIVE (send to local host) AND * Replicate to interface-1 and interface-2 AND * Load-balance among interface-3 and interface-4 > > Why not: > <nexthop-list-member> ::= (((<nexthop-chain-identifier> | (<nexthops> > ))[<nexthop-list-member-attributes]) ) > > Were you trying to name the chains? > The <nexthop-chain> tag acts like an enclosing tag for a list of next hops. It also indicates that the nexthops are related and should be treated as a chain to be applied one after the other to the same packet. Nothing magic. What it also allows (down the road) is to maintain an association of nexthop-chain contents to a chain-ID. And when a network-device supports nexthop-chain-IDs, the controller can replace the chain with just it¹s ID. Maintaining just a list of nexthops makes it harder for a controller to correlate whether 2 nexthops-list-members are effectively the same (without a bunch of crazy comparisons and sorting). Nexthop-chain tag also allows ease of understanding for Section 7.2.5. > 3) Two variables seem orphaned: > > > > Multicast-source-ipv4-address ::= <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH> > > Multicast-source-ipv6-address ::= <IPv6_ADDRESS> <IPv6_PREFIX_LENGTH> > > > Did I miss someplace where they attached to the normative section 6. > You indicated the PIM paths can be chains (section 7.3), but you do > not give the normative section. These are going to be removed. Now that you have understood a lot of the IM model, looking forward to an implementation of the same :-) Thanks Nitin
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
