Nitin: I'm glad we are getting to the detail. I think our first disconnect is not at the grammar level, but at the functional level.
IMHO your RIB functionality is insufficient as it stands because it doesn't contain the SRC-DST lookup using the packet + Meta data. RIBs should be able to match on the SRC-DST for all types of routes. I see we have a different view on the functions of look-ups. This is a terrific discussion on the RIB-Info functionality. Let's try to decide on this point, and then go back to grammar second. Will that work for you? Thanks for your patience in clearly up where our assumptions were different. Sue -----Original Message----- From: Nitin Bahadur [mailto:[email protected]] Sent: Wednesday, April 30, 2014 2:10 PM To: Susan Hares; 'Mach Chen'; [email protected] Cc: [email protected] Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 Hi Sue, Thanks for putting this down in detail. Now it¹s easier to explain what I was trying to convey. -----Original Message----- From: Susan Hares <[email protected]> >Problem: Your grammar does not handle source-destination form choice as >a generic form used by all of the interfaces. YesŠit is by design. See more below. > >Solution: Specify form as specific variable for all forms. >Confusion: I am suggesting two tags <form-tag><route-type> and you >want see one tag for compilation. > >See the two tags: [form-type] as two parts to one tag: > >[high order tag form] [low order form - address form] > >At this point, all I have done is reduce your complex forms to 1 tag ><route-type> = <form-tag><type-tag> > >Then your grammar is as follows: > ><match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> | > <mac-route> | <interface-route>) <route-type> >::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE> > ><route-type> = <form-tag><type-tag> ><form-tag> = <SRC-FORM><DST-FORM><SRC-DST FORM> Routing protocols would >have: [rrr ff ttt] r = reserved/0 ff = 0/1 (for src/dst), ttt = >type] > ><type-tag> ::=<IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE> What the above grammar does is that it allows one to construct a match that looks like: <match> ::= <SRC-DST FORM> <MPLS> <mpls-in-label> [Nitin} This is obviously incorrect. That¹s the part I have been trying to convey. In the world of routing protocols, we have IANA registries that specify what combination is legal. In the world of data-models, we can¹t depend on that. So with the grammar above, how do you prevent a badly-written controller from sending a match condition that looks like above (not that the data-model will successfully compile this match conditionŠsince the rules allow it)? [Sue]: What is obviously incorrect? I'm stating you can have source-destination possibilities on all of the functions. I think you are disagreeing on this point. > >Each of these forms for matches could use the SRC and destination in >the filter. > >I'm sure that IPv4, IPv6, and IEEE_MAC are obvious from your emails. >Interfaces can be viewed as the same for flows: <SRC-INTERFACE> ><DST-INTERFACE>. [nitin] Match is always on an incoming packet. A packet does not have embedded in it the dst-interface. So you cannot have a dst-interface as part of the match condition. [Sue]: Here is out disconnect. Match is not just on packet, but a route look-up with Meta Data with the meta data. Even Commodity chips allow meta data to be associated with the packet flows. I see a RIB look-up as including Meta data (incoming interface) and route contain outgoing interface (even if it is *(any) interface). >This can be that the traffic flow comes in on interface1 and goes out >on interface 2 for all interfaces. MPLS could but it can be >ingress/egress label as source/destination. > >Do you agree/disagree have a potential of having source-destination for >most of these types? [Nitin] I disagree that there is a potential of having a src-dst for most types. Src-dst is only possible ³in a match condition² for a route-type that has src and dest information embedded in the packet. IPv4/IPv6 & IEEE-MAC are the only possibilities. For IEEE-MAC, there has been no use-case (requirement yet) to have SRC-DST based routingŠ.so it wasn¹t included so far. [Sue]: For the MPLS and L2VPN MAC related work, the set of MPLS use cases I co-authored had this in mind. It is not an accepted use case, but it is a published use case. I suspect what I am really stating, is that SRC-DST is useful for all nodes. Thank you for being patient while we wind through the disconnect. > If you need context on the interfaces, pleases consider multicast and >flows. [Nitin]: Multicast and flows have a next-hop that points to multiple interfaces. [Sue]: It is possible to create routes where the interfaces are the key information and the IP next hop is (*). [Nitin] The incoming packet does not contain the list of outgoing interfaces. [Sue]: This is correct, but as I have noted above I am allowing for META data that would allow certain interfaces to be specified. For example, as a security measure for a VPN, it would allow only routes coming in interfaces 1-3 and going out 2-5. The meta data would contain this information as part of the routing match. Did you have this restriction in mind? Please see the white-use-case draft for this. [Nitin]: Mcast has RPF which is done based on incoming interface (which the network device knows for a given packet). So you match on mcast-address (S,G) + incoming-interface and then decide (as part of nexthop) where all and how (load-balance, multiple copies, etc) you want to send the packet. [Sue]: yes, interface(meta data) + packet in multicast as I indicated up. To nexthop (meta data + interfaces) on outgoing. Great response! I see we are arguing about functionality. Let's debate this. My UML class drawings are very short, and they helped me understand what I was missing in the functionality. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
