Hi Suresh,
Thanks for the review. Please see NB> below for comments.
Did you mean 2001:DB8::1/128 for the host route? If not, this example is
wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32
->
2001:DB8::/32 as the route
Sue: Yes - this is an error.
NB> Nice catch. Fixing it in next rev.
* Figure 4.
Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into
nexthop processing just like the derived nexthops do?
Suresh - I need to check the email list archives and get back to you on this
point. My recollection was that there was a case where things people did
not want to automatically loop this back. However, I cannot bring the
discussion of 3.5 years ago to mind. I will take this as an action item as a
reviewer to try to recreate the discussion. Thank you for mentioning this
point. It is important to clarify in either case.
NB> Sue is right that there were some cases where folks did not want the packet
to be automatically sent back for lookup. They wanted an explicit specification
on what to do with the packet. I believe the reasoning was there might be L2
processing that needs to be performed after the encap/decap and L2 processing
was mainly out of scope of this draft.
* Section 6
I would have expected the match type to have some indication about whether
it requires an exact match or LPM (e.g. A MAC route uses an exact match but
an
IPv6 route uses LPM). Has the WG discussed this?
The short answer is yes, extensive in early interims, list discussions and
in session. Can you provide more depth to your questions. For the early
discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs)
to get the institutional memory on this topic. (One of the reason I really
want to have this document discussed with Alia Atlas as AD0.
NB> Quoting from the grammar
<ipv4-route> ::= <ip-route-type>
(<destination-ipv4-address> | <source-ipv4-address> |
(<destination-ipv4-address> <source-ipv4-address>))
<destination-ipv4-address> ::= <ipv4-prefix>
<source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
Thus IP addresses have a "prefix length" associated with them indicating a LPM
(or exact-match if prefix length is 32). A MAC route is expected to have an
exact match. LPM for MAC routes was out of scope.
Thanks
Nitin
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
