[lisp] Re: Review draft-ietf-lisp-te

[Dino Farinacci <[e-mail]>]

I have posted -17. Here are responses to some of your comments.

> Do we still need to do this if the S bit is set to 0 for that hop?

Yes, because the list of RLOCs in the ELP can change.

> What is the precedence between the L bit and the S bit? Must they both be set to 1? What is the procedure of L

There isn't one, they are treated independently.

> bit =1 and S bit to 0? This handling should be defined in step 3 of the procedure

When you decide to use the address in the ELP entry, which is the next one in the list from a give RTR's position in it, who is encapsulating, then you do a lookup to find the RLOC for what is an EID at that position.

> It is must if you have L bit set. Is it appliicable  when S is set to 0 and can be skipped?
> See my comment earlier clarification on their behavior would be useful.

No not true, the L-bit is for each entry within the ELP list. What is being explained in this paragraph is if the mapping has changed. Which means a Map-Notify is sent by the mapping system if ANY RLOC-record changes.

> MUST NOT be used - 
> As this can happen at any RTR - shouldn't this be just part of the look up each time as a sanity check?
> Step 1 and Step 3?

Yes, it should be part of the validity check when a mapping is returned.

> but this is only valid if the S-bit is 0ff right?
> What happens if there is S bit set to 1 and it is unreachable?

No, if the RLOC is in the list and is unreachable, the actions from the paragraph are performed. If an EID is in the list and the RLOC it maps to is unreachable, the actions from the paragraph are performed.

> This processing is based on the AFI - 

I didn't want to add that in the early section. Because it really doesn't matter what the AFI is on the RLOC (or the EID when L=1).

Thanks for your comments,
Dino

> On Jun 2, 2024, at 10:40 PM, Padma Pillay-Esnault <[e-mail]> wrote:
> 
> Hello Authors and all.
> 
> Thanks for your patience.
> 
> First of all - I think the document describes a useful feature in LISP. Thank you for writing this doc.
> 
> I reviewed this document after reading the ELP definition in RFC8060 section 4.6.
> My overall comment is that I was expecting the detailed processing of the ELP  as  RFC8060 references this document for "details".  Therefore, I find that the document would be improved if section 5 had  detailed processing for all cases. I have flagged in the document where some processing should  be included in different steps.
>  Here are major suggestions 
> - proposed a compromise to make the document clearer on figure 1 and figure 2 and text associated.
> - proposed to beef up section 5 need to add processing of L, S, P bits but more importantly perhaps give the processing with the combinations of bits.
> 
> I am attaching the diffs in PDF format as requested in exchanges. If inconvenient. I can transform the comments in txt.
> 
> Let me know if you have any questions
> 
> Thanks
> Padma
> 
> 
> 
> 
> On Thu, May 30, 2024 at 5:33 PM Padma Pillay-Esnault <[e-mail]> wrote:
> Hello Dino and al
> 
> I will review the doc, comments, exchanges and get back to the list.
> Thanks for your patience 
> 
> Padma
> 
> On Thu, May 30, 2024 at 12:31 PM Dino Farinacci <[e-mail]> wrote:
> That is correct.
> 
> Dino
> 
> > On May 30, 2024, at 9:53 AM, Joel Halpern <[e-mail]> wrote:
> > 
> > The question, as I understand it, is not what you want Dino.  Nor is it what Luigi wants.  It is what the working group wants.  I gather that Padma has the task of figuring that out.   Good luck Padma.
> > Yours,
> > Joel
> > On 5/30/2024 12:17 PM, Dino Farinacci wrote:
> >> 
> >> 
> >>> On May 30, 2024, at 6:07 AM, Luigi Iannone <[e-mail]> wrote:
> >>> 
> >>> Dino,
> >>> 
> >>> Private emails, with insulting content, will not help progress the document.
> >> 
> >> I didn’t insult you. I made a conclusion you didn’t understand something since I repeated the explanation several times.  
> >> 
> >>> 
> >>> Since apparently we are not able to converge, my co-chair Padma accepted to handle this document from now on.
> >> 
> >> Just because commenters have comments doesn’t mean all of them need fixing. And we need to agree to disagree. 
> >> 
> >>> 
> >>> Please wait her review of the draft.
> >>> 
> >>> 
> >>> 
> >>> As a participant of the LISP WG, and with no hats on, my concerns remain unaddressed (despite proposing very detailed and easy fixes). 
> >>> 
> >>> Second example in  section 4 remains unclear and misleading. See: https://mailarchive.ietf.org/arch/msg/lisp/CzJjLCgCZquCPOkhv56-q3DZTRE/
> >>> 
> >>> The general organisation of the document can be improved.
> >>> As of now it is a bunch of use cases where for each one we see the same structure:
> >>> 
> >>> Here is a cool thing you can do using LISP ELPs….  
> >>> In order to do it you MUST do this or SHOULD do that….. 
> >>> 
> >>> In other words the specifications that need to be implemented are scattered all over the document. The risk is that people interested in one single use case will implement only part of the specs.
> >> 
> >> I implemented it and so did cisco with no problems. 
> >> 
> >>> My suggestion is to move a few paragraph in one single place so to have the document organized in two main parts: A section with all the specifications; A section with all the use cases.
> >>> My first review included detailed suggestions of the few simple cut & paste to be done: https://mailarchive.ietf.org/arch/msg/lisp/3zIUevHl8ZbqfKgwjXhJ8Z-FUlA/
> >> 
> >> Yes I know what you commented on. I don’t want to make the changes. I want to focus on all the documents that I am responsible for and this document is just not as important as the other ones. 
> >> 
> >> We have a real deadline now. I won’t be doing IETF after 2025. So now we have to be laser focused and not take > 5 years to move documents forward. 
> >> 
> >> Dino
> >> 
> >> _______________________________________________
> >> lisp mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >> 
>