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. Yesit 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> 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 conditionsince the rules allow it)? > >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>. 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. >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? 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. > If you need context on the interfaces, pleases consider multicast and >flows. Multicast and flows have a next-hop that points to multiple interfaces. The incoming packet does not contain the list of outgoing interfaces. 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. Thanks Nitin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
