Fixing a few typos > On Jun 12, 2024, at 2:37 PM, Padma Pillay-Esnault <padma.i...@gmail.com> > wrote: > > Hi Dino > > Thanks for the updates. > > For the draft 17 > -section 6 > That could be the final ETR, RLOC…where it must search for itself and use the > next RLOC in the ELP list to encapsulate to. > > This sentence a bit hard to parse. Consider to rephrase. > > > See below PPE for responses to these comments > >> On Jun 11, 2024, at 2:32 PM, Dino Farinacci <farina...@gmail.com> wrote: >> >> 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. > > PPE - Ack, i was thinking along the lines of specific skippable Reencap Hop > “n”. > >> >>> 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. > > PPE > How is the decision to skip a node taken? > Let’s take this example ( n (L=1, S=0, P=0), n+1 (L=1,S=1),…., etr) > > If we check S=0 first then the decision is just to Skip that hop “n” then > will not do a look up and go to next reencap hop n+1 . Get a valid RLOC by > performing look up for next hops in the list. (Result “n”is skipped). > > If we check first L = 1 and then there is a valid RLOC we use the reencap hop > n regardless of whether it was skippable > (Result here “n” is not skipped) > > If S =1 then we may do a look up (Result “n” not skipped) > See more below on S=1 and unreachability. > > I was wondering which is the actual behavior. As the text on S=0 is a “can > skip” it seems implementation specific and still be ok. Should some guidance > on use of L and S bit be included for clarity? FWIW I have no strong opinion > on this. > >> >>> 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. > > Ack. >> >>> 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. > Thanks >> >>> 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. > So even if S=1 for a hop, packets are not dropped when unreachable ? I was > expecting packets to be dropped if the strict hop is not reachable. > Consider the following example - hop x is to for antivirus screening then > shouldn’t packets be dropped? >> >>> 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). >> > Ack no strong opinion on that > >> Thanks for your comments, >> Dino >> >>>> On Jun 2, 2024, at 10:40 PM, Padma Pillay-Esnault <padma.i...@gmail.com> >>>> 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 >>>> <padma.i...@gmail.com> 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 <farina...@gmail.com> >>>> wrote: >>> That is correct. >>> >>> Dino >>> >>>>> On May 30, 2024, at 9:53 AM, Joel Halpern <j...@joelhalpern.com> 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 <g...@gigix.net> 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 -- lisp@ietf.org >>>>> To unsubscribe send an email to lisp-le...@ietf.org >>>>> >>> >> <draft-ietf-lisp-te-16-ppe.pdf> >>
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
