Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Nitin Bahadur <[e-mail]>]

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