Thank you
Padma
> On Jun 22, 2024, at 14:33, Dino Farinacci wrote:
>
> I will captialize.
>
> Dino
>
>> On Jun 22, 2024, at 9:24 AM, Padma Pillay-Esnault
>> wrote:
>>
>> HI Dino
>>
>> Thanks for the updates. From draft-ietf-lisp-te
>>
>> Otherwise, when the S-bit is set and an
>> xTR d
I will captialize.
Dino
> On Jun 22, 2024, at 9:24 AM, Padma Pillay-Esnault
> wrote:
>
> HI Dino
>
> Thanks for the updates. From draft-ietf-lisp-te
>
> Otherwise, when the S-bit is set and an
> xTR determines the RLOC is not reachable, it must not use any of
> the remaining entries in the E
HI Dino
Thanks for the updates. From draft-ietf-lisp-te
Otherwise, when the S-bit is set and an
xTR determines the RLOC is not reachable, it must not use any of
the remaining entries in the ELP list and drop the packet.
Shouldn't this be a "MUST not"?
Otherwise all my comments
> Here is where i wonder whether strict would have been best to drop the packet
> and not go to n+1 per the example for SFC where there are mandatory services.
>
> I think it might be worthwhile to document this behavior so as there are no
> surprises.
> Thoughts?
Will add. Thanks.
Dino
Thanks for your responses - see below
> On Jun 13, 2024, at 2:34 PM, Dino Farinacci wrote:
>
>
>
> 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.
>>>
>>
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=
Fixing a few typos
> On Jun 12, 2024, at 2:37 PM, Padma Pillay-Esnault
> 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
Thanks Padma, I will update the spec this week.
Dino
> On Jun 2, 2024, at 10:40 PM, Padma Pillay-Esnault
> 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 rev
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 wrote:
> That is correct.
>
> Dino
>
> > On May 30, 2024, at 9:53 AM, Joel Halpern wrote:
> >
> > The question, as I understand
That is correct.
Dino
> On May 30, 2024, at 9:53 AM, Joel Halpern 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,
>
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, L
> On May 30, 2024, at 6:07 AM, Luigi Iannone 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 a
> On 27 May 2024, at 16:49, Dino Farinacci wrote:
>
> I don’t see the need to fix it. And the working group doesn’t seem to care.
> If you can’t give me a compelling reason to fix it, I’m not going to.
>
> You clearly don’t understand what a network path is. It includes nodes AND
> links.
Hi Dino,
I do not see a reply to my last email.
Can you fix the figure of the example so that we can move forward?
The concerned part is:
>>
>>> This is exactly the point. I do not see an alternate path. I see only an
>>> alternate tunnel.
>>> The current text is still confusing. You want "to
> On 7 May 2024, at 16:36, Dino Farinacci wrote:
>
>
>> The text still assumes that an ELP must be returned.
>
> That is correct.
>
>>
>> Just replace the words:
>>
>> “which returns a ELP-based locator record for a path to RTR 'y', and
>> encapsulates packets…"
>
> The example is illu
> The text still assumes that an ELP must be returned.
That is correct.
>
> Just replace the words:
>
>“which returns a ELP-based locator record for a path to RTR 'y', and
> encapsulates packets…"
The example is illustrating nesting so I believe it is not needed.
Luigi, the terms
Hi Dino,
Thanks for the update.
My comments inline.
> On 6 May 2024, at 19:54, Dino Farinacci wrote:
>
> Copying the WG. I have submitted -16 to make things more clear to reflect
> your comments. Here is the diff.
>
> Dino
>> On May 6, 2024, at 5:26 AM, Luigi Iannone wrote:
>>
>> Dino,
>>
> On May 6, 2024, at 10:54 AM, Dino Farinacci wrote:
>
> Copying the WG. I have submitted -16 to make things more clear to reflect
> your comments. Here is the diff.
>
> Dino
>
<<< text/html; x-unix-mode=0644; name="draft-ietf-lisp-te-15.diff.html": Unrecognized >>>
>
>
>> On May 6, 2024,
18 matches
Mail list logo
