Nitin: 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 [mailto:nitin_baha...@yahoo.com] Sent: Friday, April 13, 2018 1:52 AM To: Susan Hares; 'Suresh Krishnan'; 'The IESG' Cc: i2rs@ietf.org; i2rs-cha...@ietf.org; draft-ietf-i2rs-rib-info-mo...@ietf.org Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Suresh: 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. Suresh> * 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. 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 i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
