Nitin:
Thanks for the detailed response. From: Nitin Bahadur [mailto:[email protected]] Sent: Wednesday, April 30, 2014 3:01 PM To: Susan Hares; [email protected] Cc: 'Jeffrey Haas'; [email protected]; Alia Atlas Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 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. Ok, then the RIB grammar stands alone. 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) . ) . [Nitin on] 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 [Nitin off] [Sue on] This functionality was evident from your earlier helpful email. However, your previous email stated you tagged this per next-hop. Did I understand each nexthop can have the following flags: 1) Special nexthops: discard, discard_with_error, receive 2) Protection_preference (primary/back-up), load_balance_weight (ecmp) If so, then I do not understand why the recursion in lists. These are just list of nexthops with flags. nexthop-list-member::= (flags) (nexthop) Or <nexthop-list-member> ::= [(<SPECIAL_NEXT_HOP> | <PROTECTION_PREFERENCE> | <LOADBALANCE>) ] (<nexthop>) Are you trying to apply the flag Meta data is applying to the next hop chain? [Sue] Why not: <nexthop-list-member> ::= (((<nexthop-chain-identifier> | (<nexthops> . ))[<nexthop-list-member-attributes]) ). Were you trying to name the chains? [Nitin on ] 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. [nitin off] [Sue on] Ok - the assumption that a nexthop-chain-list identifier would be always associated with start of chain was not clear. Could you tell me where I missed that piece of information (other than the grammar - which has it optional). Why does the grammar not say: <nexthop-chain-list>::= <nexthop-chain-identifier> (<nexthop>.) <nexthop-list-member>::=<nexthop-chain-list> [<nexthop-list-member-attributes>] <nexthop-list>:: == (<nexthop-chain-list> .) <nexthop-list-member> ::= (((<nexthop-chain-identifier> | (<nexthops> . ))[<nexthop-list-member-attributes]) ). 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. [Nitin]: Now that you have understood a lot of the IM model, looking forward to an implementation of the same :-) Thanks Nitin [Sue]: I found a lot of these issues when starting at the UML drawings and then trying to retro-fit your UML. It's all about assumptions - let's clear up the last and come to agreement the RBNF. Once we get an agreed-upon RBNF text, I will like to suggest a UML equivalent. Thanks for your responses. Sue PS - I am working with developers. See my co-authors on the UML work.
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
