>[Nitin] The main issue is that the grammar will not be deterministic.
>[Nitin] In other words, one needs a way to specify that <route-tag-1>
><rt-form-A> is valid and <route-tag-1> <rt-form-B> is NOT valid.
>
>[Sue-2 on]
>Why is the grammar not explicit? Let's put the type back in for each
>
><match_form = DST> <match_type = IPv4> <ip-v4-prefix> (addresses are
>just
>a specific type of prefix)
><match_form=SRC> <match_type = IPv4> <ipv4-prefix> (addresses are
>just a specific type of prefix)
><match_form=DST-SRC> <match_type = ipv4> <ipv4-prefix> <ipv4-prefix>
>
>This is TLV where (form-type) implies a specific length (in example, 8,8,
>16).
>If you want to go with the traditional TLV form, consider the (form-type)
>as
>a Type field,
>And put in a length field.
Unfortunately this is not our typical TLV, sub-TLV definitions specified
in IANA registryusing which one can easily see what is valid and what is
not. In fact we don¹t want anyone to refer to a registry, since all the
code is going to be auto-generated (using the data-model tooltbd).
I think I¹m just not clear on your proposal. Here is the grammar I have.
<match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |
<mac-route> | <interface-route>)
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<ipv4-route> ::= <ip-route-type> (<destination-ipv4-address> |
<source-ipv4-address> |
(<destination-ipv4-address>
<source-ipv4-address>))
<ipv6-route> ::= <ip-route-type> (<destination-ipv6-address> |
<source-ipv6-address> |
(<destination-ipv6-address> <source-ipv6-address>))
<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
<mpls-route> ::= <MPLS_LABEL>
<mac-route> ::= <MAC_ADDRESS>
<interface-route> ::= <INTERFACE_IDENTIFIER>
If you could express what you are saying in the same-way, maybe I¹ll get
more clarity.
Thanks
Nitin
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
