> Reviewer: Ines Robles
> Review result: Not Ready
>
> Reviewer: Ines Robles
> Date: 01-06-2024
> Version reviewed:draft-ietf-lisp-geo-06
Thanks for your comments. I have posted -07. See my responses to your comments
below.
> Suggestions/Issues:
>
> It would be nice to add information about:
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
> wrote:
> Hello Dino and al
>
> I will review the doc, comments, exchanges and get back to
Thank you for your comments. I will update the draft this week.
Dino
> On Jun 1, 2024, at 4:21 PM, Ines Robles via Datatracker
> wrote:
>
> Reviewer: Ines Robles
> Review result: Not Ready
>
> Reviewer: Ines Robles
> Date: 01-06-2024
> Version reviewed:draft-ietf-lisp-geo-06
>
> Summary:
>
Padma.
> Yours,
> Joel
> On 5/30/2024 12:17 PM, Dino Farinacci wrote:
>>
>>
>>> On May 30, 2024, at 6:07 AM, Luigi Iannone wrote:
>>>
>>> Dino,
>>>
>>> Private emails, with insulting content, will not help progress the document
> 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
Me too.
Dino
> On May 28, 2024, at 11:04 AM, Balaji Pitta Venkatachalapathy (bvenkata)
> wrote:
>
> Support.
> Balaji
>
>
> From: Michael McBride
> Sent: Wednesday, May 22, 2024 9:35:13 PM
> To: p...@ietf.org
> Cc: lisp@ietf.org
> Subject: [lisp]
> 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
> 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":
Just an FYI that I have submitted the following documents as a 3-set document
series to be moved along to draft standard.
draft-farinacci-lisp-rfc6831bis-00
draft-farinacci-lisp-rfc8378bis-00
draft-vdas-lisp-group-mapping-03
The reference graph dependency looks like this:
rfc6831bis
y LCAF type 5 is
> deprecated.
>
>
> Two additional points:
>
> 1. The abstract must be updated. You are now proposing a new format. You also
> need to state “This document updates RFC 8060”.
>
> 2. Section 5: Type 17 is suggested, not requested.
>
>
> C
I didn't and believe it doesn't need to go at the beginning of the document.
Dino
> On Apr 30, 2024, at 12:23 PM, Luigi Iannone wrote:
>
>
>
>> On 30 Apr 2024, at 17:41, Dino Farinacci wrote:
>>
>> I'll make all your chnages but this one comment:
>>
&g
ot;Geo-Location".
Dino
> On Apr 30, 2024, at 12:11 PM, internet-dra...@ietf.org wrote:
>
> Internet-Draft draft-ietf-lisp-geo-05.txt is now available. It is a work item
> of the Locator/ID Separation Protocol (LISP) WG of the IETF.
>
> Title: LISP Geo-Coordinate Use-Case
I'll make all your chnages but this one comment:
> On Apr 30, 2024, at 7:58 AM, Luigi Iannone wrote:
>
> routing protocols, namely OSPF [I-D.acee-ospf-geo-location], IS-IS
> [I-D.shen-isis-geo-coordinates],
It is not true. Only the GPS encoding is the same. The general encoding that
wraps
Great - thanks Luigi.
Dino
> On Apr 29, 2024, at 4:02 PM, Luigi Iannone wrote:
>
> Hi Dino,
>
> I will send you the details about changes for your document.
>
> Ciao
>
> L.
>
>
>> On 29 Apr 2024, at 19:54, Dino Farinacci wrote:
>>
>
Its above my pay grade to decide on what to do. Ball is in your court.
> We need to ask IANA for a value different from 5 and currently unassigned,
> and at the same time deprecate the encoding in RFC8060.
If that is what you think, I'm fine with it.
> Yes, this means as well fixing
now ;-)
>
> Ciao
>
> L.
>
>> On 27 Apr 2024, at 15:54, Dino Farinacci wrote:
>>
>> I browsed your comments. They are easier to interpret now. Thanks for that.
>> However, your references are not helpful because they indicate you
>> want text to be moved
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
>> Cabellos, Ed., "The Locator/ID Separation Protocol
>> (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
>> <https://www.rfc-editor.org/info/rfc9300>.
>>
l
>
> On 4/26/2024 6:05 PM, Dino Farinacci wrote:
>>> Can you find an on-list email where such a conclusion was reached. That
>>> would certainly explain your choice.
>> I searched (before I sent the last email) and could not
> Can you find an on-list email where such a conclusion was reached. That
> would certainly explain your choice.
I searched (before I sent the last email) and could not find anything. Likely
it was private.
Dino
___
lisp mailing list
> I gather you decided to change the encoding to match some other work. But
> you chose not to use a different code point when you did so. You simply
> changed the meaning, without updating the published RFC.
We did not change the code point because it was decided by the working group,
as I
> Thanks Luigi. I agree, the fact that some pre-standard implementations chose
> to change the meaning of a code pint does not make them correct.
They really didn't. They did implement RFC 8060, and when lisp-geo was written,
we decided to change.
Dino
> As for the implementations… more than the number of implementations what
> really matters is the deployments.
If this truly matters …
> In the lack of these conditions the only reasonable action IMO is to use a
> different type value.
… then you made a contradiction.
You don't want to
See previous emails.
> How many implementations are using RFC 8060 and will be impacted?
That’s too general a question because there are many use-case codepoints in it.
I have to look at my notes I think there were other pending updates to RFC
8060.
Dino
efit to the change we should
> step up, admit we are changing it, and explain why.
>
> Yours,
>
> Joel
>
> On 4/23/2024 11:48 AM, Dino Farinacci wrote:
>>> As I said, the simplest solution is to use a different type value. This
>>> allows to still use th
> As I said, the simplest solution is to use a different type value. This
> allows to still use the old encoding and does not obsoletes implementations
> that use it.
You will obsolete implementations if we do that. Which really means you make
the spec irrelevant. So I say stay with the same
I will add. Thanks for the text.
>> This sentence should be placed at the end of section 5, where you describe
>> the encoding.
Okay. See diff enclosed.
Dino
<<< text/html; x-unix-mode=0644; name="draft-ietf-lisp-geo-03.diff.html": Unrecognized >>>
You have to judge that. We do have references that point to ISIS and OSPF.
Dino
> On Apr 18, 2024, at 8:14 AM, Luigi Iannone wrote:
>
>
>
>>> On 18 Apr 2024, at 16:19, Dino Farinacci wrote:
>>>
>>> LISP geo-location decided to use the encoding
LISP geo-location decided to use the encoding format consistent and coordinated
with the routing protocols.
Dino
> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault
> wrote:
>
>
> Hello Dino and Alberto
>
> The Yang Doctor review had comments on Yang -20 draft regarding the geoloc.
>
I support this draft for WG adoption. Mostly because, its the best idea I have
heard about putting routing protocols in space and I trust no one other than
Tony to keep it simple.
The LISP WG is working on running overlays over satellite networks assuming the
underlay knows how to route across
In favor.
Dino
> On Jan 11, 2024, at 7:52 AM, Luigi Iannone wrote:
>
> Hi All,
>
> Happy new year!
>
> As you may have seen from Alberto’s shepherd review of the name encoding
> document, it is suggested to move the document to standard track.
>
> Jim Guichard (our AD) is OK as long as
Can you fix one typo please:
Change "ruining" to "running". ;-)
Thanks,
Dino
> On Dec 28, 2023, at 3:00 AM, Alberto Rodriguez-Natal (natal)
> wrote:
>
> Hi all,
> The shepherd’s review of the LISP Distinguished Name Encoding has been
> posted. The document is in good shape and minor
inor nits: - Please include a reference and the boilerplate
> for RFC 2119.
> - Please update the reference from RFC 1700 (obsolete) to RFC 3232 (current).
> Thanks,
> Alberto
> From: Alberto Rodriguez-Natal (natal)
> Date: Thursday, December 14, 2023 at 12:05 PM
> To: Dino
Thanks for the comments Roberto. See comments inline.
> First my apologies, this is long overdue. I’m trying to catch up with my
> shepherd’s review of draft-ietf-lisp-name-encoding and I have some
> comments/suggestions on the current draft.
I have submitted draft-ietf-lisp-name-encoding-03
> ### "LISP", paragraph 0
> ```
> - NAT-Traversal: Support for a NAT-traversal solution in deployments where
> LISP
> tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).
> ```
> Stick it into UDP and use existing NAT traversal solutions.
> Re-engineering all that does not
> What about putting Geo on March and TE on July? With good chances that we
> finish everything before July.
That makes a lot more sense IMO. Since there has been little commentary on TE
in a decade!
Dino
___
lisp mailing list
lisp@ietf.org
Thanks a lot.
Dino
> On Oct 26, 2023, at 2:46 AM, Luigi Iannone wrote:
>
> Ack,
>
> done
>
> L.
>
>> On Oct 25, 2023, at 18:18, Dino Farinacci wrote:
>>
>> Prasad requested to present (I will present since Prasad won't be in Pr
> Concerning Geo, I understand that from your perspective the work is done,
> however, if we put it on March 2024 then we have 4 docs to work on.
> I prefer to spread a bit so to smooth the workload (for shepherd+AD).
Start on lisp-geo now and we can finish it before March 2024. It has already
uter for the
> Locator/Identifier Separation Protocol
> • https://atlas.cs.uni-tuebingen.de/~menth/papers/Menth23c.pdf
> • 10 Minutes (Cumulative Time: 50 Minutes)
> • Michael Menth
>
>
> • DEMO: gaapchat IPv6 multicast app over LISP over Starlink
>
, October 20, 2023 at 7:53 AM
To: Alberto Rodriguez-Natal (natal)
Cc: Luigi Iannone , Dino Farinacci , LISP mailing list list , lisp-cha...@ietf.org
Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
Hi everyone,
I fixed some nits and addressed my previous editorial
encoding, RFC 8060 and 9306 (Standards Track). We are
> already there ...
> As the dates proposed are target dates, i suggest we keep the date of June
> 2024 but if we can go faster it is all good. thoughts?
>
> Similar comment for mobility.
>
> Thanks
> Padma
>
&
> What do you think of putting some major milestones for mobility and security
> sections rather than per document?
I think security is further out compared to mobility. Just because other groups
will have to peer-review the security documents. But good suggestion and will
incldue below the
> HTTP! And to make things more confusing, it was up to a router to pull from
> specific sources, like RIRs.
Right, so it was a "pull-all-state" protocol. Not a push, like BGP would do it.
Dino
___
lisp mailing list
lisp@ietf.org
> Yes, that would do it.
Please ack if these diffs satisfy your comments.
Thanks,
Dino
<<< text/html; x-unix-mode=0644; name="draft-farinacci-lisp-decent-12.diff.html": Unrecognized >>>
___
lisp mailing list
lisp@ietf.org
But not all push based systems use
> multicast. The definitions of push-based and pull-based should be general.
> Decent-pulll and decent-push (or some other terms) can be defined as this
> document uses them.
>
> Yours,
>
> Joel
>
> On 10/16/2023 3:36 PM, Dino Farinac
> Relative to the LISP mapping system, the terms pull-based and push-based long
> predate this draft. There was an original push-based mapping system proposed
> (in which all mappings were pushed to all ITRs). While we decided not to
> advance that,
Right, the LISP-Decent pushed-based uses
Looking at what you put earlier versus later is not based on the reality of the
readiness of the documents. Here are some comments:
(1) Nov 2023 should be Submit Name-Encoding to IESG.
(2) Geo-Coordinates has been stable for a long time where NAT-traversal is so
far from ready. The June date
I support this draft. Cisco put a lot of effort into this and their customers
seem to appreciate it.
Dino
> On Oct 12, 2023, at 5:35 AM, Luigi Iannone wrote:
>
> All,
>
> During the last LISP WG meeting the authors of the draft:
>
> LISP Site External Connectivity
>
I support this document because it’s the simplest of mapping systems we have
ever developed. I have tested it on 10 map-servers with 10M EID entries spread
across them.
If folks want to hear more about this I can present 2-3 slides in Prague. 10
minutes max.
Dino
> On Oct 12, 2023, at 5:35
> If you want to present during our meeting please send an email to the chairs
> at latest by Monday October 23.
I am planning a demo for the PIM WG. I could present that demo in the LISP WG.
The title is:
"gaapchat IPv6 multicast app over LISP over Starlink"
I would only need 15 minutes.
> I propose that we change the wording of "Standard Track Documents: The core
> specifications of LISP have been published as “Standard Track” [references].
> The WG will continue moving select specifications to “Standard Track”."
That sounds good to me.
Dino
> PPE - I see security as a use case but grouping the draft here does not
> imply any restriction on its uses beyond.
I see security a fundamental and required mechanism for all use-cases.
Dino
___
lisp mailing list
lisp@ietf.org
> Hi Dino,
>
> A few comments inline
>
>> On Oct 7, 2023, at 00:54, Dino Farinacci wrote:
>>
>> Here are my comments. The charter text comes first and is indented and my
>> comments follow:
>>
>>> LISP Working Group Charter ProposalPropose
Here are my comments. The charter text comes first and is indented and my
comments follow:
> LISP Working Group Charter ProposalProposed Charter: Introduction
> LISP supports a routing architecture which decouples the routing locators and
> identifiers, thus allowing for efficient
"...
> PPE: It was proposed to merge the experimental RFCs RFC6831 & RFC8378.
> However, how they are used in Replication List entries is in
> https://datatracker.ietf.org/doc/draft-vda-lisp-underlay-multicast-trees/.
> It is still open if all three docs should be merged in a big document or
>
I would like a 15 minute slot to present "LISP Multicast over Starlink"
progress. It includes running a new group allocation protocol (GAAP) on top of
the overlay too.
Thanks,
Dino
> On Jun 26, 2023, at 12:33 PM, Luigi Iannone wrote:
>
> Hi All,
>
> The LISP WG has been scheduled for Monday
> "this describes a shortcut we took, not compliant with [RFC9300] and
> [RFC9301],
> which works among consenting parties when no one else is using the particular
> values in any other way, but we do not recommended it for arbitrary
> deployments.”
I will add in next revision.
Dino
>>>
>>> Now, let’s take one step back: the real question seems to be how to signal
>>> in the mapping system that an RLOC belongs to a RTR?
>>
>> You could do it with a distinguished-name AFI that is encoded with the RLOC
>> address.
>
> Excellent. So we have another possibility beside
e do not recommended it for arbitrary
> deployments" then I would probably have fewer concerns. As you say, you did
> indeed do it.
>
> Yours,
>
> Joel
>
> On 5/24/2023 1:55 PM, Dino Farinacci wrote:
>>> Trimmed, In line.
>>>
>>> On 5/2
> Trimmed, In line.
>
> On 5/24/2023 1:45 PM, Dino Farinacci wrote:
>>> there are a few things to ponder:
>>>
>>> - Looking at lispers.net the 254 value choice, it looks like a quick hack.
>> I would refer to it as a convienent solution
> there are a few things to ponder:
>
> - Looking at lispers.net the 254 value choice, it looks like a quick hack.
I would refer to it as a convienent solution that doesn't violate the spec.
> - What about backward compatibility? If we allow overloading, there is no way
> to understand
> So... I think it's good to document what people will see in the wild. A 254
> priority is probably a good signal that one is dealing with a lispers.net
> implementation. To me at least, the goal here should be to permit the
> documenting of that use. Documenting that in an RFC seems like a
> Personally, I find this to be an inappropriate overlaoding of the Priority.
> While overloading is not uncommon, it often causes problems with protocols
> and I would prefer that we not do so.
We all do. But the implementation has been deployed for nearly 10 years. The
draft is just
Maybe I can provide some color, so folks know why this design decision was
made.
(1) An xTR behind a NAT will register its global RLOC (and port) and the RTRs
it has learned to the mapping system.
(2) When another ITR wants to encapsulate to this xTR, it CANNOT do so with the
global RLOC.
(3)
om the on-line Internet-Drafts
> directories.
>
> Title : LISP Multicast Overlay Group to Underlay RLOC Mappings
> Authors : Vengada Prasad Govindan
> Dino Farinacci
> Aswin Kuppusami
> Stig Venaas
> On the other hand, the draft proposes the recursive approach that *prepend*s
> more than one header. I'm confused of the
Only when you need to perserve an outer RLOC based header. Just like MPLS uses
service-in-service through an ISP with stacked headers. But I think it would be
rarely used
Prakash, I reviewed the diff and the changes look real good to me.
Thanks,
Dino
> On Mar 28, 2023, at 4:02 AM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : LISP Site External Connectivity
>
> I don't believe we should have a non PubSub option. Its what we have now to
> update xTRs map-caches. Its slow and we can do better. Since we have PubSub
> in a mature state, we should have this design depend on it fully.
>
>
> PJ>>> As per current draft, both options are available, however
> Dino,
> Back then Albert Lopez, Vina and others invested quite some time addressing
> in draft-ermagan-lisp-nat-traversal a lot of corner cases that were coming
> from mobiity.
>
> Before we move forward with a NAT document we should make sure we either
> explicitly leave out those use
draft-farinacci-lisp-lispers-net-nat proposes an implemented solution for the
problem.
Dino
> On Mar 21, 2023, at 6:25 AM, Albert López wrote:
>
> On 14/3/23 10:46, Luigi Iannone wrote:
>> LISP NAT Traversal: we have a candidate document
>
> Here we have the problem of handovers between
> They can still be experimental if WG is willing to publishing them. The
> charter may include a security/privacy work item and these documents would be
> covered.
Right - agree.
Dino
___
lisp mailing list
lisp@ietf.org
>> PPE- should we consider predictive rlocs draft as well? It covers predictive
>> mobility.
Yes - it covers a more efficient mobility. Good point - I missed that.
Dino
___
lisp mailing list
lisp@ietf.org
> Hi LISP WG,
>
> As for the subject, this email starts the discussion about: From Experimental
> to ST: these are a bunch of RFC that may be considered to move ST
>
> There are a few experimental RFCs which is worth to be considered to be moved
> to standard track (if we have documented
> LISP Mobility: candidate document LISP-MN but does not solve everything
> should we enlarge the scope?
draft-ietf-lisp-eid-mobility as well.
> LISP Yang Model: We are pretty close to finish this one
> LISP NAT Traversal: we have a candidate document
And VPNs are in charter and used quite a
Can I request 10 minutes for draft-farinacci-lisp-satellite-network.
Thanks,
Dino
> On Mar 7, 2023, at 6:10 AM, Luigi Iannone wrote:
>
> Hi All,
>
> Our LISP session has been scheduled.
> We have two full hours.
>
> Please send to the chairs your request for a presentation slot no later
recommendations/assumptions.
> Thanks,
> Alberto
> From: lisp on behalf of Dino Farinacci
>
> Date: Thursday, February 16, 2023 at 12:31 AM
> To: lisp@ietf.org list
> Cc: i-d-annou...@ietf.org
> Subject: Re: [lisp] I-D Action: draft-ietf-lisp-pubsub-13.txt
> Comment:
&g
Comment:
>
And how does a Map-Resolver verify a Map-Request? There is no security
association with it unless it uses draft-ietf-lisp-ecdsa-auth.
And what does "an xTR is allowed to use" mean? Based on what, a white-list in
the Map-Resolver, which is intractable?
And for point (2), how does
> Well, the security folks usually want a stateless solution to this sort of
> problem. The nonce increment requries keeping state per pending
> correspondent.
Agree.
Dino
___
lisp mailing list
lisp@ietf.org
Tell me what you all think. Can the map-server just store the nonce and then the next Map-Request have the map-server require nance+1?Stops reply attacks at only the cost of storing an additional 64 bits. Do you think that solves the problem?DinoOn Feb 15, 2023, at 10:49 AM, Joel Halpern
We should look at the mechanisms of lisp-sec to see if they can be used for
this algorithm. I think the OTK is the token and hash Joel describes below but
doesn't include a timestamp.
The algorithm, would require two Map-Requests to be sent, as Joel said, and
would add subscription delay.
be misleading to convey a Map-Register message which is not the intent. So I conclude no change should be made. DinoOn Feb 12, 2023, at 4:59 PM, Erik Kline wrote:On Sun, Feb 12, 2023 at 2:46 PM Dino Farinacci <farina...@gmail.com> wrote:The Map-Request registry can point to both 9301 and the ne
>> The Map-Request registry can point to both 9301 and the new LISP PubSub RFC.
>
> That works, yes.
>
> I was wondering about the fact that the message itself just grew an extra 2
> fields.
It shouldn’t have.
Which fields are you referring to? If you are referring to site-ID and xTR-ID,
> Thanks for the review Erik! Not sure what would be the preferred way to
> proceed here, since PubSub is a nice to have but not required optimization of
> RFC 9301. Would like to hear what others think.
The Map-Request registry can point to both 9301 and the new LISP PubSub RFC.
Dino
It all looks fine to me.
Dino
> On Jan 18, 2023, at 10:58 AM, David Dong via RT
> wrote:
>
> Dear Albert Cabellos, Dino Farinacci (cc: lisp WG),
>
> As the designated experts for the LISP Control Plane Header Bits: Map-Request
> registry, can you review the proposed
> On Jan 10, 2023, at 5:16 PM, Prakash Jain (prakjain)
> wrote:
>
> PJ>>> As per current draft, both options are available, however we are open
> to discuss and conclude it either way for the best solution. Would like to
> hear if any other opinion on this.
Please lead the design with
> • (Dino): Elaborate on the update mechanisms/message types ( legacy
> LISP or pub-sub preferred??).
> (Authors): A shorter TTL would be a simple measure to allow update in non
> pub-sub (Standard/Legacy LISP) mode. With pub-sub, N-bit would be set in a
> Map-Request, then Map-Notify
ol WG of the
> IETF.
>
>Title : LISP Geo-Coordinate Use-Cases
>Author : Dino Farinacci
> Filename: draft-ietf-lisp-geo-01.txt
> Pages : 14
> Date: 2022-12-12
>
> Abstract:
> This draft describes how G
>
> Hi Dino,
>
>> On 9 Dec 2022, at 22:20, Dino Farinacci wrote:
>>
>> I agree with all your comments and will do a revision.
>>
>> Regarding Type 5, that type was previously allocated *for this draft*.
>> Sometimes it is hard to remember sinc
S-IS", Work in Progress, Internet-Draft,
>> draft-shen-isis-geo-coordinates-04, 18 October 2017,
>> <https://www.ietf.org/archive/id/draft-shen-isis-geo-
>> coordinates-04.txt>.
>>
>> Appendix A. Acknowledgments
>>
>>
I encourage people to have a read of the document. Its an easy read.
Dino
> On Dec 9, 2022, at 5:01 AM, Luigi Iannone wrote:
>
> Hi,
>
>
>> On 22 Nov 2022, at 21:12, Dino Farinacci wrote:
>>
>> I was asked by Luigi at the LISP WG meeting to start a d
> Hi Luigi, all,
>
> I also think that it is reasonable to publish this spec as a proposed
> standard.
+1.
Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
> Maybe terminology will clarify this the best.
>
> Typically EID means address of hosts which can move between network locations.
I would argue it means an ID of anything. Traditionally, an EID is an ID of a
host but has evolved into a VM, a service, and now more opaque objects per your
> Dino, you can submit a new revision with the usual naming convention
> draft-ietf-lisp-geo-00
Just submitted waiting chairs approval.
> You can also start to address the comments you received during the last
> meeting.
I already did in the draft-farinacci-lisp-geo-15 draft. Please review.
I was asked by Luigi at the LISP WG meeting to start a discussion about this
document and solicit review for comments.
Does the WG think this should be a working group document?
Please send comments. Thanks.
Dino
___
lisp mailing list
lisp@ietf.org
I think we are past the period for WG adoption. Can I change
draft-farinacci-lisp-geo-15 to draft-ietf-lisp-geo-00?
And I solicit comments to reflect the discussion in the minutes. So would like
to request last call for draft-ietf-lisp-geo-00?
Dino
> On Nov 22, 2022, at 6:50 AM, Luigi Iannone
o
> Begin forwarded message:
>
> From: Sharon Barkai
> Subject: Re: Lisp Portable Edge Multipoint Sockets
> Date: November 20, 2022 at 11:30:45 PM PST
> To: Dino Farinacci
> Cc: Fabio Maino , Albert Cabellos ,
> Jordi , Alberto Rodriguez-Natal
>
> Thats all very tr
work item of the Locator/ID Separation Protocol WG of the
> IETF.
>
>Title : LISP Geo-Coordinate Use-Cases
>Author : Dino Farinacci
> Filename: draft-farinacci-lisp-geo-15.txt
> Pages : 13
> Date: 2022-11-10
>
> My 2 cents:
>
> • I'm unsure about this sentence: "Endpoint Identifiers (EIDs) and
> Routing Locators (RLOCs) which are intended to replace most use of IP
> addresses on the Internet."
I have plans to do an update based on Alvaro's comments in the WG. I will fix
that. I think it was
Yes agree. Wherever IP addresses are stored in payload - they need to be
translated and should be spec’ed in detail in the NAT-traversal spec (currently
an expired draft).
Dino
> On Nov 7, 2022, at 10:39 AM, Alberto Rodriguez-Natal (natal)
> wrote:
>
> Agreed, that something we should
erto
>
> [1] https://mailarchive.ietf.org/arch/msg/lisp/hN4tpuZl2nm86UVTqqmH24q0Tx8/
>
>
> From: Dino Farinacci
> Date: Sunday, November6 2022 at 2:39 PM
> To: Alberto Rodriguez-Natal (natal)
> Cc: Alvaro Retana , lisp@ietf.org ,
> Luigi Iannone , lisp-cha...@
> [AR] As mentioned in the Alvaro/Dino discussion, regular Map-Notifies as per
> 9301 are sent to the source IP address of the Map-Register that triggered
> them. Since PubSub extends LISP to specify that Map-Notifies can also be
> triggered by Map-Requests, we need to specify where these
>
1 - 100 of 857 matches
Mail list logo
