Thanks for fixing Suresh's comments.  I've trimmed the text below to text 
tunnel-encap/decap text and LPM text.  

I will do a deep dive on the tunnel encap/decap on the mail list to see if I 
can find any additional comments to help your text.  However, I suspect that 
what you will naturally write will be the best text. 

On the LPM, let's see if Suresh has a suggestion on where to add text.   Again, 
I'm sure you will do a great job writing up the text. 

Would you remember to send the revised text to Warren and to Ignas.  We could 
really use their review of the revisions for these two points.   Warren and 
Ignas have experience with RIBs. 

Sue Hares 

-----Original Message-----
From: Nitin Bahadur [] 
Sent: Friday, April 13, 2018 1:52 AM
To: Susan Hares; 'Suresh Krishnan'; 'The IESG'
Subject: Re: [i2rs] Suresh Krishnan's No Objection on 
draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

    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.

Sue> Could you put this in the draft?  It makes my recollection.  I will be 
doing a deep dive on the I2RS mail list and presentation today to provide 
additional test. 

    * 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
    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.

Sue: This matches my understanding.   If Suresh is confused, others will be.  
Let's see if Suresh has a suggestion on where to add text.  Will you follow up 
with Suresh on this point? 

i2rs mailing list

Reply via email to