Nitin:
Let me start with my perception of the problem:
Problem: Your grammar does not handle source-destination form choice as a
generic form used by all of the interfaces.
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>
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>. 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?
Your grammar could then be restated:
================================
<match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |
<mac-route> | <interface-route>)
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<form-type> ::= <SRC> | <DEST> | <DEST_SRC>
<ipv4-route> ::= (<destination-ipv4-address> | <source-ipv4-address> |
(<destination-ipv4-address>
<source-ipv4-address>))
<ipv6-route> ::= (<destination-ipv6-address> | <source-ipv6-address> |
(<destination-ipv6-address> <source-ipv6-address>))
<form-type> ::= <SRC> | <DEST> | <DEST_SRC>
<mpls-route> :: = ( (egress-MPLS-label) | (Ingress-MPLS_LABEL>) |
(<egress-mpls-label><ingress-MPLS_LABEL>))
<mac-route> ::= > (<DST-MAC_ADDRESS> | [<SRC-MAC-ADDRESS>] |
(<DST_MAC_ADDRESS><SRC-MAC-ADDRESS>))
<interface-route> ::= (<DST-INTERFACE_IDENTIFIER> |
<SRC-INTERFACE-IDENTIFIER> | (<DST-INTERFACE-IDENTIFIER>
<SRC-INTERFACE-IDENTIFIER>) )
If you need context on the interfaces, pleases consider multicast and flows.
The rest hopefully is QED based the above grammar. If we can start with
this, I hopefully, you can see the extension to other forms n-tuple and
next-hops.
Sue
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
