[lisp] Re: Review draft-ietf-lisp-te
> 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 are used in self contained sections. They are fine. S-EID is ONLY used in the multicast section because the is the convention we use to look up a multicast mapping (S-EID, G-EID). > > I think a unique term makes more sense, but this is not a blocking point. It is a unique term. The term S-EID is used in all the multicast drafts to describe an (S,G). > 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 route around the path from > B to C” and to do it you route "through link B—>C”. This looks like a > contradiction to me. B and C have other links. Don’t you see the link between B and X. That is “another” path. > The sentence remains superfluous. Of course you can do it with ODL, but this > is out of the scope of the IETF and I do not see why it should be there. > The other LISP documents never mention a provision system, so why this one > has to mention it? Is there a compelling reason? Because in other cases ETRs register their own RLOCs because they know them. With an ELP, a provisioning system knows the topology and can register all the addresses in the ELP. It has a broader view. There are deployments that take an ISIS topology, compute paths offline as an SDN controller, and can build an ELP path based on policy rules (where re-encapsulation points can be placed in the network). Dino ___ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
[lisp] Re: Review draft-ietf-lisp-te
> 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, at 5:26 AM, Luigi Iannone wrote: >> >> Dino, >> >> The document is WG document and the WG has a say. >> Please post your reply to the mailing list. I will reply there. >> >> At least we make the WG aware of how we work to move the document forward. >> ;-) >> >> Ciao >> >> L. >> >>> On 4 May 2024, at 01:32, Dino Farinacci wrote: >>> >>> Going private. >>> >>>> On May 3, 2024, at 4:41 AM, Luigi Iannone wrote: >>>> >>>> Dino, >>>> >>>> Let’s go step by step. >>>> >>>> Let’s postpone the text relocation and focus first on the other concerns I >>>> have. >>> >>> Good. >>> >>>> On 2 May 2024, at 22:29, Dino Farinacci wrote: >>>>> >>>>> Luigi, see the diff file for most of your comments. I still cannot follow >>>>> your move suggestions. Just moving text around away from where they are, >>>>> are going to lose points I intended. You need to be crystal clear what >>>>> text needs to move where and be precise why you think so. I feel the text >>>>> doesn't need moving. So if you think it does you need to make compelling >>>>> reasons without destroying the flow and meaning I have intended. >>>>> >>>>> I made all the changes you requested in this diff file. I have comments >>>>> for what I didn't change (I didn't comment on the move text since I did >>>>> above). >>>>> >>>>>> Dino, you correct text mixes specifications and use cases. By >>>>>> concentrating the specifications in one section (namely section 5) you >>>>>> will improve readability and clarity of the document. >>>>> >>>>> No it doesn't. You are using the term use-cases in a high level sense. We >>>>> are discuss functionality and why the ELP is needed. >>>> >>>> No Dino. You are mixing examples and procedures, hence my suggestion to >>>> move around some text. But we will deal with this later. >>> >>> I am presenting the material as I see fit to make it understandable. >>> >>>> >>>>>> What really request is a mapping, which may or may not be an ELP. >>>>>> What happens if it receives a negative map-reply? >>>>> >>>>> It follows the procedures of RFC9301. And we don't need to state this >>>>> everywhere. We are assuming the reader knows how LISP works at a high >>>>> level. >>>> >>>> So your text is wrong because it states "requests the ELP for RTR ‘y’”. >>>> You request a mapping and act upon what you receive, you do not request an >>>> ELP for ‘y’. >>> >>> I will fix this to be more clear. >>> >>>> >>>>>> You mean that this second lookup can be done on a mapping system that is >>>>>> different from the one who delivered the initial ELP, right? >>>>>> If yes, can you state so? >>>>> >>>>> It means the ELP entry is an EID, so to get the RLOC for that EID, you do >>>>> another lookup. It gives another level of indirection within an ELP. >>>> >>>> The sentence I referring to is: This can be done when using a public or >>>> private mapping database. >>>> >>>> Why are you introducing this distinction between public and private? >>> >>> Because the recursion can be done with a private database. Its a useful >>> feature. >>> >>>> >>>>> >>>>>> The document uses a mix of “seid” and “S-EID”, choose one. >>>>> >>>>> >>>>> On purpose. The seid and deid are used in the forwarding examples. The >>>>> (S-EID) is only in the multicast section. >>>> >>>> But you do not explain de difference. Either uniform them or explain. As >>>> it is now is just confusing. >>> >>> Luigi, the terms are used in self contained section
[lisp] LISP multicast overlay standard set documents submitted
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 -> rfc6831 rfc8378bis -> rfc6831bis vdas-group-mapping -> rfc6831bis and rfc8378bis Check Change Log in each appendix for changes. XML files have been uploaded. Thanks, Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
Please provide text and tell me where you prefer the paragraph starting with "This document proposes …" to go. Dino > On May 2, 2024, at 6:07 AM, Luigi Iannone wrote: > > Dino, > > You missed the important part, the fact that the document updates 8060 and > deprecates types 5. > The current text still say that the format is specified in 8060, which is not > the case anymore. > Here is the suggested text again: > > This document proposes a new LCAF encoding for geo-coordinates, which is > compatible with the one used in other > routing protocols, namely OSPF [I-D.acee-ospf-geo-location], IS-IS > [I-D.shen-isis-geo-coordinates], > and BGP [I-D.chen-idr-geo-coordinates]. This document updates [RFC8060]. In > particular, the use of geo-coordinates > encoding defined in Section 4.3 of [RFC8060] and identified by 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. > > > Ciao > > L. > > >> On 30 Apr 2024, at 18:31, Dino Farinacci wrote: >> >> 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: >>>> >>>>> 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 the GPS encoding is LCAF. You do not want to mislead that OSPF >>>> and ISIS use LCAF. >>> >>> Agreed. You can add exactly this details. >>> >>> Thanks >>> >>> Luigi >>> >>>> >>>> Dino >>>> >>> >> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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: >> >>> 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 the GPS encoding is LCAF. You do not want to mislead that OSPF and >> ISIS use LCAF. > > Agreed. You can add exactly this details. > > Thanks > > Luigi > >> >> Dino >> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-geo-05.txt
I had to IAAN request Type value 17 (and not 15 since RFC8060 had already spec'ed type values 15 and 16). And I wasn't sure if it was implied by Luigi's comments, but the name of this encoding needs to be different than the "Geo-Coordinates type 15" in RFC8060, so it is called "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-Cases > Author: Dino Farinacci > Name:draft-ietf-lisp-geo-05.txt > Pages: 15 > Dates: 2024-04-30 > > Abstract: > > This draft describes how Geo-Coordinates can be used in the LISP > Architecture and Protocols. Some use-cases can be geo-fencing and > physically locating objects. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-geo/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-geo-05 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-geo-05 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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 the GPS encoding is LCAF. You do not want to mislead that OSPF and ISIS use LCAF. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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 implementations that shouldn’t have used >>> type 5 in the first place. >> >> Yes, but be realistic. You know what this means. Implementations will accept >> both type values until there is enough evidence that no one uses the old >> type anymore. >> >> Dino >> >> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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 implementations that shouldn’t have used type > 5 in the first place. Yes, but be realistic. You know what this means. Implementations will accept both type values until there is enough evidence that no one uses the old type anymore. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Review draft-ietf-lisp-te
Okay, thanks. So this email has an updated version of your comments. Right? Dino > On Apr 29, 2024, at 5:24 AM, Luigi Iannone wrote: > > Hi Dino, > > It was marked to append the text to section 5. > > I’ve added to mark the exact spot, should be easier > 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 but you don’t say where. So please clarify that before >> I make any changes. >> >> Dino >> >>> On Apr 26, 2024, at 9:16 AM, Luigi Iannone wrote: >>> >>> Comments inline. >>> >>> Ciao >>> >>> L. >>> >>>> >>>> >>>> Internet Engineering Task Force D. Farinacci >>>> Internet-Draft lispers.net >>>> Intended status: Experimental M. Kowal >>>> Expires: 24 October 2024 cisco Systems >>>> P. Lahiri >>>> 22 April 2024 >>>> >>>> >>>> LISP Traffic Engineering >>>> draft-ietf-lisp-te-15 >>>> >>>> Abstract >>>> >>>> This document describes how LISP re-encapsulating tunnels can be used >>>> for Traffic Engineering purposes. The mechanisms described in this >>>> document require no LISP protocol changes but do introduce a new >>>> locator (RLOC) encoding. The Traffic Engineering features provided >>>> by these LISP mechanisms can span intra-domain, inter-domain, or >>>> combination of both. >>>> >>>> Status of This Memo >>>> >>>> This Internet-Draft is submitted in full conformance with the >>>> provisions of BCP 78 and BCP 79. >>>> >>>> Internet-Drafts are working documents of the Internet Engineering >>>> Task Force (IETF). Note that other groups may also distribute >>>> working documents as Internet-Drafts. The list of current Internet- >>>> Drafts is at https://datatracker.ietf.org/drafts/current/. >>>> >>>> Internet-Drafts are draft documents valid for a maximum of six months >>>> and may be updated, replaced, or obsoleted by other documents at any >>>> time. It is inappropriate to use Internet-Drafts as reference >>>> material or to cite them other than as "work in progress." >>>> >>>> This Internet-Draft will expire on 24 October 2024. >>>> >>>> Copyright Notice >>>> >>>> Copyright (c) 2024 IETF Trust and the persons identified as the >>>> document authors. All rights reserved. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Farinacci, et al. Expires 24 October 2024 [Page 1] >>>> >>>> Internet-Draft LISP Traffic Engineering April 2024 >>>> >>>> >>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>> Provisions Relating to IETF Documents (https://trustee.ietf.org/ >>>> license-info) in effect on the date of publication of this document. >>>> Please review these documents carefully, as they describe your rights >>>> and restrictions with respect to this document. Code Components >>>> extracted from this document must include Revised BSD License text as >>>> described in Section 4.e of the Trust Legal Provisions and are >>>> provided without warranty as described in the Revised BSD License. >>>> >>>> Table of Contents >>>> >>>> 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 >>>> 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 >>>> 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 >>>> 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 >>>> 5. Explicit Locator Paths . . . . . . . . . . . . . . . . . . . 5 >>>> 5.1. ELP Re-optimization . . . . . . . . . . . . . . . . . . . 7 >>>> 5.2. Using Recursion . . . . . . . . . . . . . . . . . . . . . 8 >>>> 5.3. ELP Selection based on Class of Service . . . . . . . . . 8 >>>> 5.4. Packet Loop Avoidance . . . . . . . . . . . . . . . . . . 9 >>>> 6. Service Chaining . . . . . . . . . . . . . . . . . . . . . .
Re: [lisp] Review draft-ietf-lisp-te
t answer. The MAY opens the door to security > issues. > How does this work with LISP-SEC? IMO there is no changes needed, it just > works out of the box. Would be good to state it explicitly. > > I would add a sentence about new attacks. Refer to RFC7835 and state if there > are additional attack. If not, just state explicitly that no new attack > vectors are introduced by this mechanism. >> 12. IANA Considerations >> >>This document does not make any request to IANA. >> >> 13. References >> >> 13.1. Normative References >> >>[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, >> DOI 10.17487/RFC0791, September 1981, >> <https://www.rfc-editor.org/info/rfc791>. >> >>[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", >> STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, >> <https://www.rfc-editor.org/info/rfc1034>. >> >>[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, >> DOI 10.17487/RFC2119, March 1997, >> <https://www.rfc-editor.org/info/rfc2119>. >> >>[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 >> (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, >> December 1998, <https://www.rfc-editor.org/info/rfc2460>. >> >> >> >> >> >> Farinacci, et al.Expires 24 October 2024 [Page 14] >> >> Internet-Draft LISP Traffic Engineering April 2024 >> >> >>[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, >> A., Peterson, J., Sparks, R., Handley, M., and E. >> Schooler, "SIP: Session Initiation Protocol", RFC 3261, >> DOI 10.17487/RFC3261, June 2002, >> <https://www.rfc-editor.org/info/rfc3261>. >> >>[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The >> Locator/ID Separation Protocol (LISP) for Multicast >> Environments", RFC 6831, DOI 10.17487/RFC6831, January >> 2013, <https://www.rfc-editor.org/info/rfc6831>. >> >>[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, >> "Interworking between Locator/ID Separation Protocol >> (LISP) and Non-LISP Sites", RFC 6832, >> DOI 10.17487/RFC6832, January 2013, >> <https://www.rfc-editor.org/info/rfc6832>. >> >>[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical >> Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, >> February 2017, <https://www.rfc-editor.org/info/rfc8060>. >> >>[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC >> 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, >> May 2017, <https://www.rfc-editor.org/info/rfc8174>. >> >>[RFC9300] 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>. >> >>[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, >> Ed., "Locator/ID Separation Protocol (LISP) Control >> Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, >> <https://www.rfc-editor.org/info/rfc9301>. >> >> 13.2. Informative References >> >>[I-D.ermagan-lisp-nat-traversal] >> Ermagan, V., Farinacci, D., Lewis, D., Maino, F., >> Portoles-Comeras, M., Skriver, J., White, C., Brescó, A. >> L., and A. Cabellos-Aparicio, "NAT traversal for LISP",
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
I think this is what transpired. (1) we wrote lisp-geo with exact packet syntax as RFC 8060. (2) We received comments from Enke, Naiming, Chris Hopps, and Acee. (3) We changed the format to be consistent with OSPF, ISIS, and BGP (the lisp-geo Document Change section documents this and when). (4) I asked if we could change RFC 8060 and pretty sure Luigi said yes. That’s my memory. Dino > On Apr 26, 2024, at 6:07 PM, Joel Halpern wrote: > > It's up to Luigi and Padma, but my read is that if it was private it was not > a WG decision. > > Yours, > > Joel > > 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 find anything. >> Likely it was private. >> >> Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> 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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> 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 recall, that we could modify RFC 8060 with the new format from lisp-geo. > Sorry, that is squatting on and misusing a code point. The correct remedy is > for the squatter to move to use a different code point.Even if you think > there are no implementations of the code point from the RFC. (Which would be > very hard to know, since no, you don't consult to all the implementors.) This was so long ago, but we asked, and I for one, thought that was the decision. And I believe, that cisco went the same route as my implementation. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> 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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> 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 change the type at all to respect the implementations. So that means lisp-geo stays the same and you either (1) ignore RFC 8060 or (2) change type in RFC 8060, should be our action. That is the simpliest solution without more disruption. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
My preference is to update RFC 8060. Dino > On Apr 23, 2024, at 12:24 PM, Joel Halpern wrote: > > From where I sit, doing nothing should be a non-starter. We have a published > RFC. We are allowed to change our mind. > > But... > > 1) We need to be explicit about making such a change. Which involves > updating the existing RFC. > > 2) Any such change needs to explain why it is being changed. Just because a > later implementation did it differently, without a standard, does not justify > changing the standard. If there is an actual benefit 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 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 code point. >> >>> Option B. This document officially updates 8060, but this means that >>> existing implementation of the 8060 encoding are not valid anymore. >> Right. But so much time has passed between from when the lisp-geo spec was >> published I believe most implementations have done lisp-geo encoding vs RFC >> 8060. My lispers.net implementation does the lisp-geo encoding with the type >> defined in the draft which is the same as RFC 8060. >> >>> How many implementation of this draft are you aware of? >> I think cisco and lispers.net. But cisco has to confirm. >> >> I think we should do Option C which is do nothing to RFC 8060 and put text >> in the lisp-geo spec which indicates its encoding takes precedent over RFC >> 8060 using the same code point and document all implementations have evolved >> to the lisp-geo spec. >> >> Dino >> >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> 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 code point. > Option B. This document officially updates 8060, but this means that existing > implementation of the 8060 encoding are not valid anymore. Right. But so much time has passed between from when the lisp-geo spec was published I believe most implementations have done lisp-geo encoding vs RFC 8060. My lispers.net implementation does the lisp-geo encoding with the type defined in the draft which is the same as RFC 8060. > How many implementation of this draft are you aware of? I think cisco and lispers.net. But cisco has to confirm. I think we should do Option C which is do nothing to RFC 8060 and put text in the lisp-geo spec which indicates its encoding takes precedent over RFC 8060 using the same code point and document all implementations have evolved to the lisp-geo spec. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> P.s. > > Just noticed that this document proposes an encoding which is not the same as > the one in RFC 8060 but use the same type number. That is right, we chose a format consistent with the IGPs so RFC8060 has to updated. I made this clear when the change was made. Since so much time passes since we are not being productive, the same arguments resurface years later. And its getting harder and harder for people to remember and keep context. So should I submit a change to RFC 8060 and call it RFC 8060bis? > This is not possible. The best solution would be to use a different type > number. The implementations use the latest in the draft. > On 22 Apr 2024, at 13:23, Luigi Iannone wrote: >> >> Dino, >> >> You did put a reference to other protocols in the acknowledgement section. >> This is not enough. >> >> You should put a sentence like: >> >> The encoding format is consistent with the encoding used in other routing >> protocols, namely: OSPF [I-D.acee-ospf-geo-location], IS-IS >> [I-D.shen-isis-geo-coordinates], and BGP [I-D.chen-idr-geo-coordinates] >> protocols. 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 >>> >> >> Ciao >> >> L. >> >> >> >>> On 18 Apr 2024, at 17:19, Dino Farinacci wrote: >>> >>> 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 format consistent and >>>>> coordinated with the routing protocols. >>>>> >>>> >>>> Is this clearly state in the document? >>>> >>>> L. >>>> >>>>> 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. >>>>>> For reference comment from Joe Clark >>>>>> As to the two questions asked here, I can see some benefit of breaking >>>>>> out the IANA parts of address-types into a module that they maintain. >>>>>> But in its current form, I don't know that it makes sense to have them >>>>>> maintain it. As for geoloc, I do see some overlap, but I am not a LISP >>>>>> expert at all, so I cannot comment as to whether bringing that whole >>>>>> module in makes sense or would even work with LISP implementations. That >>>>>> is, it seems LISP lat and long are expressed in degrees° >>>>>> minutes'seconds" whereas geoloc does this as a decimal64 from a >>>>>> reference frame. I do feel that whatever direction is taken, text >>>>>> explaining why geoloc is not used is useful. >>>>>> >>>>>> Per Med's comment on groupings - >>>>>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/ >>>>>> >>>>>> Consolidating these comments in a single thread here for resolution and >>>>>> discussion on the list before the refresh, >>>>>> >>>>>> Thanks >>>>>> Padma and Luigi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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 format consistent and >>> coordinated with the routing protocols. >>> >> >> Is this clearly state in the document? >> >> L. >> >> 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. >>> For reference comment from Joe Clark >>> As to the two questions asked here, I can see some benefit of breaking out >>> the IANA parts of address-types into a module that they maintain. But in >>> its current form, I don't know that it makes sense to have them maintain >>> it. As for geoloc, I do see some overlap, but I am not a LISP expert at >>> all, so I cannot comment as to whether bringing that whole module in makes >>> sense or would even work with LISP implementations. That is, it seems LISP >>> lat and long are expressed in degrees° minutes'seconds" whereas geoloc does >>> this as a decimal64 from a reference frame. I do feel that whatever >>> direction is taken, text explaining why geoloc is not used is useful. >>> >>> Per Med's comment on groupings - >>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/ >>> >>> Consolidating these comments in a single thread here for resolution and >>> discussion on the list before the refresh, >>> >>> Thanks >>> Padma and Luigi >>> >>> >>> >>> >>> >>> >>> >>> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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. > For reference comment from Joe Clark > As to the two questions asked here, I can see some benefit of breaking out > the IANA parts of address-types into a module that they maintain. But in its > current form, I don't know that it makes sense to have them maintain it. As > for geoloc, I do see some overlap, but I am not a LISP expert at all, so I > cannot comment as to whether bringing that whole module in makes sense or > would even work with LISP implementations. That is, it seems LISP lat and > long are expressed in degrees° minutes'seconds" whereas geoloc does this as a > decimal64 from a reference frame. I do feel that whatever direction is > taken, text explaining why geoloc is not used is useful. > > Per Med's comment on groupings - > https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/ > > Consolidating these comments in a single thread here for resolution and > discussion on the list before the refresh, > > Thanks > Padma and Luigi > > > > > > > > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Queue closed on Tony's satellite I-D
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 ISLs. So this will be complementary work. For more information see: https://datatracker.ietf.org/doc/draft-farinacci-lisp-satellite-network/ In this draft, only user-stations and gateways run LISP and the mapping system runs on earth. Dino > On Mar 19, 2024, at 1:39 AM, Tony Li wrote: > > > Hi Sue, > >> +1 to Adrian – This is good work. The text continues to improve > > > Thanks! > >> On the grid idea, have you done theoretical or simulations to look at the >> grid model? Grid for this problem and the striping seemed like a good >> approach to add this concept. > > I have not. Without some way of validating a simulation, it seems like an > exercise in pure confirmation bias. > > Tony > > ___ > rtgwg mailing list > rt...@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Moving draft-ietf-lisp-name-encoding to standard track?
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 the WG is OK with this change and that > deployment experience is added to the document. > > Hence, this email opens a two weeks call to check if you agree with the > change. > > Please reply to this email stating whether you are in favor or you are > against. > (Silence does not count) > > Please reply. > > Ciao > > L. > > >> Begin forwarded message: >> >> From: "Alberto Rodriguez-Natal \(natal\)" >> Subject: [lisp] Shepherd's review of draft-ietf-lisp-name-encoding >> Date: December 28, 2023 at 12:00:33 GMT+1 >> To: "lisp@ietf.org" >> >> Hi all, >> The shepherd’s review of the LISP Distinguished Name Encoding has been >> posted. The document is in good shape and minor identified nits have been >> fixed. Please find the review here: >> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/shepherdwriteup/ >> However, as part of the review, it was raised the question if the document >> is in the right stream (currently in Experimental). Given that there are >> known implementations of the spec and that it has been running in production >> for some time, my suggestion is to consider moving this document to >> Standards track instead. >> Thanks, >> Alberto >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Shepherd's review of draft-ietf-lisp-name-encoding
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 identified nits have been > fixed. Please find the review here: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/shepherdwriteup/ > However, as part of the review, it was raised the question if the document > is in the right stream (currently in Experimental). Given that there are > known implementations of the spec and that it has been running in production > for some time, my suggestion is to consider moving this document to Standards > track instead. > Thanks, > Alberto ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Distinguished Name comments
Fixed. New draft-ietf-lisp-name-encoding-04 posted. Din <<< text/html; x-unix-mode=0644; name="draft-ietf-lisp-name-encoding-03.diff.html": Unrecognized >>> > On Dec 14, 2023, at 6:31 AM, Alberto Rodriguez-Natal (natal) > wrote: > > Just two more minor 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 Farinacci > Cc: lisp@ietf.org > Subject: Re: Distinguished Name comments > Hi Dino, > Changes look mostly good to me, thanks! Just one comment, how about this > wording for the last paragraph of section 6? > > It is RECOMMENDED that each use-case register their Distinguish Names with > a unique Instance-ID. For any use-cases which require different uses for > Distinguish Names within an Instance-ID MUST define their own Instance-ID and > structure syntax for the name registered to the Mapping System. See the > encoding procedures in [I-D.ietf-lisp-vpn] for an example. > Also, please consider double checking that we are consistent with names > (capitalizations, dashes, etc) through the document. I think the official > spellings are “EID-Prefix” and “Distinguished Name”, it might be worth to > scan the document and update where needed. > Thanks! > Alberto > From: Dino Farinacci > Date: Wednesday, December 13, 2023 at 11:22 PM > To: Alberto Rodriguez-Natal (natal) > Cc: lisp@ietf.org > Subject: Re: Distinguished Name comments > 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 to reflect your comments > with a diff file attached. > > > >• Sec 3: You describe that when a DN is used as an EID, an exact match > > > is performed (which is correct). However, this is described in the format > > > section of the document, shouldn’t this be discussed somewhere else > > > (maybe on its own section)? I know this is a very short document, but > > > having that behavior described in the format section seems odd to me. No > > > strong opinion though. > > I have added a new section. > > > • Sec 4: You say it in the title of the section already, but it might > > be interesting that on the body of the section you mention that the listed > > use-cases are examples and more importantly that we explicitly say that > > that other use-cases not listed are possible as well. Typo: s/ascii/ASCII > > Made the change. > > > • Sec. 5: I think that this section should talk about unique > > Instance-IDs (IIDs), not VPNs, so that the text is more general while > > preserving the considerations about name collisions. We can point to the > > VPN draft to mention one example of how a particular use-case is > > registering DNs in unique IIDs, see also the next point on this. > > Made the change. > > >• Sec. 8: If we talk about IIDs in Section 5, there is no need to keep > > the VPN draft as a Normative Reference and could be moved to Informative, > > easing the RFC process. > > Fixed. > > Thanks again, > Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Distinguished Name comments
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 to reflect your comments with a diff file attached. > >• Sec 3: You describe that when a DN is used as an EID, an exact match > > is performed (which is correct). However, this is described in the format > > section of the document, shouldn’t this be discussed somewhere else (maybe > > on its own section)? I know this is a very short document, but having that > > behavior described in the format section seems odd to me. No strong opinion > > though. I have added a new section. > • Sec 4: You say it in the title of the section already, but it might be > interesting that on the body of the section you mention that the listed > use-cases are examples and more importantly that we explicitly say that that > other use-cases not listed are possible as well. Typo: s/ascii/ASCII Made the change. > • Sec. 5: I think that this section should talk about unique Instance-IDs > (IIDs), not VPNs, so that the text is more general while preserving the > considerations about name collisions. We can point to the VPN draft to > mention one example of how a particular use-case is registering DNs in unique > IIDs, see also the next point on this. Made the change. >• Sec. 8: If we talk about IIDs in Section 5, there is no need to keep the > VPN draft as a Normative Reference and could be moved to Informative, easing > the RFC process. Fixed. Thanks again, Dino <<< text/html; x-unix-mode=0644; name="draft-ietf-lisp-name-encoding-02.diff.html": Unrecognized >>> ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Lars Eggert's No Objection on charter-ietf-lisp-04-04: (with COMMENT)
> ### "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 seem worthwhile. We are not starting from scratch and have used previous ideas. This has been deployed by various implementations for 10 years now. Its the WG catching up with implementations. That's the world we live in these days. You are too familiar with this. This effort is simply a bit of clerical work. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] My comments to latest updates to LISP charter
> 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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP WG Agenda
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 Prague) >> draft-vdas-lisp-group-mapping-01. If there is not enough time, then can you >> replace the gaapchat slot with draft-vdas-lisp-group-mapping-01. >> >> The IPv6 gaapchat demo will be presented in the PIM WG for those who want to >> see it. >> >> Thanks, >> Dino >> >>>> On Oct 25, 2023, at 1:42 AM, Luigi Iannone wrote: >>> >>> All, >>> >>> Hereafter the preliminary agenda for the LISP WG meeting (also available >>> at:https://datatracker.ietf.org/meeting/118/materials/agenda-118-lisp-01) >>> >>> Please let us know if there is anything missing or wrong. >>> >>> Thanks >>> >>> Ciao >>> >>> L. >>> >>> >>> Administration >>> • Padma/Luigi/Alberto >>> • Agenda Bashing >>> • Status reports for WG drafts >>> • Rechartering Status >>> • 20 Minutes (Cumulative Time: 20 Minutes) >>> WG Items >>> • LISP Reliable Transport >>> • >>> https://datatracker.ietf.org/doc/draft-ietf-lisp-map-server-reliable-transport/ >>> • 10 Minutes (Cumulative Time: 30 Minutes) >>> • Balaji Pitta Venkatachalapathy >>> >>> >>> • LISP L2/L3 EID Mobility Using a Unified Control Plane >>> • https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/ >>> • 10 Minutes (Cumulative Time: 40 Minutes) >>> • Marc Portoles Comeras >>> >>> >>> Non WG Items >>> • DEMO: P4-LISP: A P4-Based High-Performance Router 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 >>> • https://datatracker.ietf.org/doc/draft-farinacci-pim-gaap/ >>> • 10 Minutes (Cumulative Time: 60 Minutes) >>> • Dino Farinacci >>> >>> >>> • Discussion >>> • 0 Minutes (Cumulative Time: 60 Minutes) >>> >>> ___ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] My comments to latest updates to LISP charter
> 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 been started since we had AD review. And we had some IESG review already as well (Chris Hopps). Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP WG Agenda
Prasad requested to present (I will present since Prasad won't be in Prague) draft-vdas-lisp-group-mapping-01. If there is not enough time, then can you replace the gaapchat slot with draft-vdas-lisp-group-mapping-01. The IPv6 gaapchat demo will be presented in the PIM WG for those who want to see it. Thanks, Dino > On Oct 25, 2023, at 1:42 AM, Luigi Iannone wrote: > > All, > > Hereafter the preliminary agenda for the LISP WG meeting (also available > at:https://datatracker.ietf.org/meeting/118/materials/agenda-118-lisp-01) > > Please let us know if there is anything missing or wrong. > > Thanks > > Ciao > > L. > > > Administration > • Padma/Luigi/Alberto > • Agenda Bashing > • Status reports for WG drafts > • Rechartering Status > • 20 Minutes (Cumulative Time: 20 Minutes) > WG Items > • LISP Reliable Transport > • > https://datatracker.ietf.org/doc/draft-ietf-lisp-map-server-reliable-transport/ > • 10 Minutes (Cumulative Time: 30 Minutes) > • Balaji Pitta Venkatachalapathy > > > • LISP L2/L3 EID Mobility Using a Unified Control Plane > • https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/ > • 10 Minutes (Cumulative Time: 40 Minutes) > • Marc Portoles Comeras > > > Non WG Items > • DEMO: P4-LISP: A P4-Based High-Performance Router 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 > • https://datatracker.ietf.org/doc/draft-farinacci-pim-gaap/ > • 10 Minutes (Cumulative Time: 60 Minutes) > • Dino Farinacci > > > • Discussion > • 0 Minutes (Cumulative Time: 60 Minutes) > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
I would phrase it “LISP xTRs” rather than “tunnel routers”. DinoOn Oct 20, 2023, at 2:26 AM, Alberto Rodriguez-Natal (natal) wrote: Hi Padma, Fixes seem fine to me, thanks! Maybe another suggestion, how about this text for mobility? “Mobility: Some LISP deployment scenarios include endpoints that move across different tunnel routers and/or tunnel routers that are themselves mobile, hence, support needs to be provided in order to achieve seamless connectivity.” https://github.com/lisp-wg/wg-charter/pull/11/ Thanks! Alberto From: Padma Pillay-Esnault Date: Friday, 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 comments on "Moving to Standards Track:" and "Yang Model:". It can be found here https://github.com/lisp-wg/wg-charter/pull/10/files. Let me know if you have any further comments. Thanks Padma On Wed, Oct 18, 2023 at 11:38 PM Padma Pillay-Esnault <padma.i...@gmail.com> wrote: Approved and merged. On Wed, Oct 18, 2023 at 10:05 AM Alberto Rodriguez-Natal (natal) <na...@cisco.com> wrote: Hi all, I just sent a PullRequest in GitHub with some edits. You can find it here: https://github.com/lisp-wg/wg-charter/pull/9 To keep the discussion on the list, here are the main points: - I switched the Name Encoding and Yang deliverable dates. I have action items on both (shepherd for the first and author for the second), and I feel Yang might require some time to get it done, while Name Encoding is almost there. I don’t think flipping these two dates has major implications. - I removed this sentence from the Yang item: “These management methods should be considered for both the data-plane, control plane, and mapping system components.” I think it is probably redundant and it might confuse more than clarify (isn’t mapping system a subset of control plane?) - I polished the language on the milestones to be consistent across the different items (using the same sentence structure, etc). I also use “document(s)” for the document bundles and those items further in the future, so we are flexible in how to address them. Other than that, it’s just minor edits. Let me know if you have any comment. Thanks! Alberto From: Luigi Iannone <g...@gigix.net> Date: Tuesday, October 17, 2023 at 2:01 PM To: Padma Pillay-Esnault <padma.i...@gmail.com> Cc: Dino Farinacci <farina...@gmail.com>, LISP mailing list list <lisp@ietf.org>, lisp-cha...@ietf.org <lisp-cha...@ietf.org> Subject: Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub] Hi Dino, Padma, The list of milestones I proposed does not have more than 2 item per deadline, which is reasonable to me. However, some milestones do indeed refer to several documents like Privacy and Security, Multicast, and mobility. IMO there is no need to list the detailed documents and if we finish before the schedule this is a plus not a problem. Since Nov 2023 is in 2 weeks I agree with Padma that there is no need to rush. The name encoding document was indeed missing, since it is a simple document we can publish it by March 2024. The update list looks like: 1. November 2023: Submit a LISP Yang model document to the IESG for consideration 2. March 2024: Submit LISP Traffic Engineering document to the IESG for consideration 3. March 2024: Submit LISP Reliable Transport document to the IESG for consideration 4. March 2024: Submit LISP Name Encoding document to the IESG for consideration 5. June 2024 : Submit LISP geo-coordinates to the IESG for consideration 6. June 2024: Submit a LISP NAT Traversal document to the IESG for consideration 7. November 2024: Submit 8111bis to the IESG for consideration 8. November 2024: Submit merged LCAFbis document to the IESG for consideration 9. March 2025: Submit LISP Privacy and Security documents to the IESG for consideration 10. March 2025: Submit 6832bis Proxy XTRs document to the IESG for consideration 11. June 2025: Submit LISP Mobile documents to the IESG for consideration 12. November 2025: Submit Multicast documents to the IESG for consideration 13. March 2026: Submit LISP Applicability document to the IESG for consideration 14. November 2026: Wrap-Up or recharter Better? L. On Oct 17, 2023, at 01:46, Padma Pillay-Esnault <padma.i...@gmail.com> wrote: Hi Dino The groupings look good! Some dates look too aggressive Nov 2023: draft-ietf-lisp-geo, draft-ietf-lisp-name-encoding, RFC 8060 and 9306 (Standards Track). We are already there ... As the dates proposed are target da
Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
June 24 for both LCAF related and mobility sets? Fine with me. Dino > On Oct 16, 2023, at 4:46 PM, Padma Pillay-Esnault > wrote: > > Hi Dino > > The groupings look good! > > Some dates look too aggressive Nov 2023: draft-ietf-lisp-geo, > draft-ietf-lisp-name-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 > > On Mon, Oct 16, 2023 at 4:35 PM Dino Farinacci wrote: > > 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 set that go together (IMO). > > So here is what I suggest: > > For June 2024: Mobility documents as a set to IESG, which include: > > draft-ietf-lisp-eid-mobility, draft-ietf-lisp-mn, > draft-ietf-lisp-predictive-rlocs, draft-ietf-lisp-vpn > > And for June 2025: Security documents as a set to IESG, which include: > > draft-ietf-lisp-crypto (RFC8061 to Standards Track), > draft-ietf-lisp-ecdsa-auth, draft-ietf-lisp-eid-anonymity > > And then, not related to what you asked for, to put all LCAF related stuff in > one set: > > For Nov 2023: > > draft-ietf-lisp-geo, draft-ietf-lisp-name-encoding, RFC 8060 and 9306 > (Standards Track) > > What do you think? > > Dino > > > > > > > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
> 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 set that go together (IMO). So here is what I suggest: For June 2024: Mobility documents as a set to IESG, which include: draft-ietf-lisp-eid-mobility, draft-ietf-lisp-mn, draft-ietf-lisp-predictive-rlocs, draft-ietf-lisp-vpn And for June 2025: Security documents as a set to IESG, which include: draft-ietf-lisp-crypto (RFC8061 to Standards Track), draft-ietf-lisp-ecdsa-auth, draft-ietf-lisp-eid-anonymity And then, not related to what you asked for, to put all LCAF related stuff in one set: For Nov 2023: draft-ietf-lisp-geo, draft-ietf-lisp-name-encoding, RFC 8060 and 9306 (Standards Track) What do you think? Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] The LISP WG has placed draft-farinacci-lisp-decent in state "Call For Adoption By WG Issued"
> 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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] The LISP WG has placed draft-farinacci-lisp-decent in state "Call For Adoption By WG Issued"
> 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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] The LISP WG has placed draft-farinacci-lisp-decent in state "Call For Adoption By WG Issued"
I can change the spec to be more specific as you suggest. Would that work for you? Dino > On Oct 16, 2023, at 12:38 PM, Joel Halpern wrote: > > To point to one example of the problem, this draft defines "push based" as > using multicast. Decent uses multicast. 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 Farinacci wrote: >>> 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 multicast. The other one, NERD, >> used management protocols and not a control plane if I recall. >> >>> the term had an understood meaning. Also, pull-based and push-based have >>> well-defined meaning in many contexts. This draft >> The pull-based is what all the mapping systems are using. For LISP-Decent we >> wanted to distinguish the pull-based mechanism based on hashing from the >> push-base multicast method. >> >>> seems to use those terms in a rather idiosyncratic (not incorrect, but >>> confusing) fashion. I am not sure whether different terms or additional >>> qualifiers are the better solution. >> Did I make it clearer? >> >> Dino >> >>> Yours, >>> >>> Joel >>> >>> On 10/16/2023 9:40 AM, IETF Secretariat wrote: >>>> The LISP WG has placed draft-farinacci-lisp-decent in state >>>> Call For Adoption By WG Issued (entered by Luigi Iannone) >>>> >>>> The document is available at >>>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-decent/ >>>> >>>> >>>> ___ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] The LISP WG has placed draft-farinacci-lisp-decent in state "Call For Adoption By WG Issued"
> 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 multicast. The other one, NERD, used management protocols and not a control plane if I recall. > the term had an understood meaning. Also, pull-based and push-based have > well-defined meaning in many contexts. This draft The pull-based is what all the mapping systems are using. For LISP-Decent we wanted to distinguish the pull-based mechanism based on hashing from the push-base multicast method. > seems to use those terms in a rather idiosyncratic (not incorrect, but > confusing) fashion. I am not sure whether different terms or additional > qualifiers are the better solution. Did I make it clearer? Dino > > Yours, > > Joel > > On 10/16/2023 9:40 AM, IETF Secretariat wrote: >> The LISP WG has placed draft-farinacci-lisp-decent in state >> Call For Adoption By WG Issued (entered by Luigi Iannone) >> >> The document is available at >> https://datatracker.ietf.org/doc/draft-farinacci-lisp-decent/ >> >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]
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 for NAT-traversal is too aggressive. Geo-Coordinates should be Nov 2023. (3) There is no mention of the VPN document. That too has been running for a decade and stable. That should be submitted Nov 2023 or at least Mar 2024. (4) What about the other mobility drafts that go along with LISP Mobile Node? (5) What about the security drafts? Seems the list below is not complete to me. Dino > On Oct 16, 2023, at 6:52 AM, Luigi Iannone wrote: > > Good points Padma, > > > What about the following ordering? > > 1. November 2023: Submit a LISP Yang model document to the IESG for > consideration > 2. March 2024: Submit LISP Traffic Engineering document to the IESG for > consideration > 3. March 2024: Submit LISP Reliable Transport document to the IESG for > consideration > 4. June 2024 : Submit LISP geo-coordinates for consideration > 5. June 2024: Submit a LISP NAT Traversal document to the IESG for > consideration > 6. November 2024: Submit 8111bis to the IESG for consideration > 7. November 2024: Submit merged LCAFbis document to the IESG for consideration > 8. March 2025: Submit LISP Privacy and Security documents to the IESG for > consideration > 9. March 2025: Submit 6832bis Proxy XTRs document to the IESG for > consideration > 10. June 2025: Submit LISP Mobile Node to the IESG for consideration > 11. November 2025: Submit Multicast documents to the IESG for consideration > 12. March 2026: Submit LISP Applicability document to the IESG for > consideration > 13. November 2026: Wrap-Up or recharter > > L. > >> On Oct 13, 2023, at 19:49, Padma Pillay-Esnault wrote: >> >> Additional comments/suggestions >> >> Milestones >> To be consistent, we should have at least a milestone for each of the larger >> sections. There is a couple missing: >> - TE section - suggest March 2025 >> - Privacy and Security section - suggest Nov 2025 or March 2026 >> >> Format >> To be consistent with other sections, we should have "Yang Model:" format. >> >> Ordering >> I would not propose to order as sections matching the milestones as sections >> may have different documents at different maturity levels. However this one >> caught my attention: should we move up "NAT transversal" section to after >> "Yang Model:" as it is in March 2024. >> >> Thanks >> Padma >> >> >> On Fri, Oct 13, 2023 at 10:21 AM Padma Pillay-Esnault >> wrote: >> Hi Luigi >> >> Looks good to me >> nit/suggestion below see PPE >> >> Padma >> >> On Fri, Oct 13, 2023 at 2:05 AM Luigi Iannone wrote: >> Hi, >> >> I’ve tried to merge the list of work items in the charter in a single list >> and created a PR. >> >> Items have been merged and re-ordered in the following way: >> First the general standard track work item (multicast work merged here) >> Then other work with drafts more advanced appearing earlier. >> Milestone list will be updated once WG converged on this part. >> >> The list looks like: >> >> Main work items are identified as follows: >> • Standard Track Documents: The core specifications of LISP have been >> published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue >> the work of moving select specifications to “Standard Track” (e.g., >> [RFC8060], [RFC8111] and the set of multicast documents like [RFC6831] and >> [RFC8378]). >> >> PPE - Reading this the "standard track document" bullet kinda implies that >> the docs below are not standard track. >> Suggestion - "Moving to Standard tracks:" >> >> >> • YANG models for managing the LISP protocol and deployments that >> include data models, OAM, as well as allowing for programmable management >> interfaces. These management methods should be considered for both the >> data-plane, control plane, and mapping system components. >> • Map Server Reliable Transport: LISP control plane messages are >> transported over UDP, however, in some cases, the use of a reliable >> transport protocol is a better fit, since it actually helps reduce periodic >> signaling. >> • LISP for traffic engineering: Specifics on how to do traffic >> engineering on LISP deployments could be useful. For instance, encode in a >> mapping not only the routing locators associated to EIDs, but also an >> ordered set of re-encapsulating tunnel routers used to specify a path. >> • LISP external connectivity: [RFC6832] defines the Proxy ETR element, >> to be used to connect LISP sites with non-LISP sites. However, LISP >> deployments could benefit from more advanced internetworking, for instance >> by defining mechanism to discover such external connectivity. >> • NAT-Traversal: Support for NAT-traversal solution in deployments where >> LISP
Re: [lisp] Confirm WG adoption for document draft-jain-lisp-site-external-connectivity
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 > https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/ > > Asked for adoption as WG document. > Call for adoption during the meeting showed clear consensus (see: > https://datatracker.ietf.org/doc/minutes-117-lisp/) > This email is the usual procedure to confirm the consensus on the mailing > list. > > If anybody has concerns about adopting this document please state so on the > mailing list before October 26, 2023 > Please also argument the technical reason why you have concerns. > > Ciao > > Luigi, Padma, Alberto > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Call for adoption for document draft-farinacci-lisp-decent
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 AM, Luigi Iannone wrote: > > > Hi All, > > As you may have seen in the thread about the WG rechartering, authors of the > document "A Decent LISP Mapping System (LISP-Decent)” did ask the chairs to > open a call for adoption. > See message: > https://mailarchive.ietf.org/arch/msg/lisp/6QXqTtDYalSIN9740queg7ZuvYc/ > You can find the document at: > https://datatracker.ietf.org/doc/draft-farinacci-lisp-decent/ > > This email formally opens the two weeks Call for Adoption. > > If you are supporting adoption, please state so. > If you have concerns, please detail them. > > The call will close on October 26, 2023. > > Luigi, Padma, Alberto > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Call for LISP WG agenda items
> 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. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Proposed WG Charter on GitHub
> 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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Proposed WG Charter on GitHub
> 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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Proposed WG Charter on GitHub
> 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 ProposalProposed Charter: Introduction >>> LISP supports a routing architecture which decouples the routing locators >>> and identifiers, thus allowing for efficient >> >> "... supports an overlay routing …" > > Is it really necessary? Well I think so since we changed the solution space of LISP from "saving the routing tables" to a more general overlay solution. > >>> aggregation of the routing locator space and providing persistent >>> identifiers in the identifier space. LISP requires no changes to >>> end-systems or to routers that do not directly participate in the LISP >>> deployment. LISP aims for an incrementally deployable protocol, so new >>> features and services can be added easily and quickly to the network using >>> overlays. The scope of the LISP technology is potentially applicable to >>> have a large span.The LISP WG is chartered to continue work on the LISP >>> protocol and produce standard-track documents. >> >> I would add some of the more explicit features that overlay routing can do >> and how LISP actually has done so and specified at a very detailed level. >> Some examples are mobility, VPNs, multicast, mix protocol family, all with >> the latest in security mechanisms. > > We are not promoting LISP here, we are listing the work items. Let’s keep it > simple and to the point. That is okay, but you did give some basic features as you describe "how it works". > >> >>> Proposed Charter: Work Items Part 1 >>> • NAT-Traversal: Support for NAT-traversal solution in deployments where >>> LISP tunnel routers are separated from correspondent tunnel routers by a >>> NAT (e.g., LISP mobile node). >>> • YANG models for managing the LISP protocol and deployments that include >>> data models, OAM, as well as allowing for programmable management >>> interfaces. These management methods should be considered for both the >>> data-plane, control plane, and mapping system components. >>> • Multicast Support: LISP support for multicast environments has a >>> growing number of use cases. Support for multicast is needed in order to >>> achieve scalability. The current documents [Ref to experimental multicast >>> RFCs] should be merged and published as Standard Track. >> >> I think the smaller work items that we can knock out should be in Part 1 >> like geo-coordinates and name-encoding. > > Geo coordinates is part of the mobility bullet point. Right, that is misplaced IMO. GPS can be used for mobility but none of the mobility drafts that state mechanisms refer to it. Like VPNs and TE, GPS is its own category. > >> And there is no mention of VPN and TE support. It needs to go in somewhere. > > VPN is later on. TE is indeed missing, we need to include it somewhere. Ack. > >> >>> Proposed Charter: Work Items Part 2 >>> • Standard Track Documents: The core specifications of LISP have been >>> published as “Standard Track” [references]. The WG will continue the work >>> of moving select specifications to “Standard Track”. >>> • Mobility: Some LISP deployment scenarios include mobile nodes (in >>> mobile environments) or Virtual Machines (VMs in data centers), hence, >>> support needs to be provided in order to achieve seamless connectivity. >>> • Privacy and Security: The WG will work on topics of EID anonymity, VPN >>> segmentation leveraging on the Instance ID, and traffic anonymization. The >>> reuse of existing mechanisms will be prioritized. >> >> I would not call VPN segmentation as security. I view it more as topological >> member grouping. > > Which is also used for security purposes. >> Right but goes beyond it. >>> • LISP Applicability: In time, LISP has proved to be a very flexible >>> protocol that can be used in various use-cases not even considered during >>> its design phase. RFC 7215, while remaining a good source of information, >>> covers one single use case, which is not anymore the main LISP application >>> scenario. The LISP WG will document LISP deployments for most recent and >>> relevant use-cases so as to update RFC 7215. >>> Proposed Charter: Tentative Milestones >>> • November 2023: Submit a LISP Y
Re: [lisp] Proposed WG Charter on GitHub
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 "... supports an overlay routing …" > aggregation of the routing locator space and providing persistent identifiers > in the identifier space. LISP requires no changes to end-systems or to > routers that do not directly participate in the LISP deployment. LISP aims > for an incrementally deployable protocol, so new features and services can be > added easily and quickly to the network using overlays. The scope of the LISP > technology is potentially applicable to have a large span.The LISP WG is > chartered to continue work on the LISP protocol and produce standard-track > documents. I would add some of the more explicit features that overlay routing can do and how LISP actually has done so and specified at a very detailed level. Some examples are mobility, VPNs, multicast, mix protocol family, all with the latest in security mechanisms. > Proposed Charter: Work Items Part 1 > • NAT-Traversal: Support for NAT-traversal solution in deployments where > LISP tunnel routers are separated from correspondent tunnel routers by a NAT > (e.g., LISP mobile node). > • YANG models for managing the LISP protocol and deployments that include > data models, OAM, as well as allowing for programmable management interfaces. > These management methods should be considered for both the data-plane, > control plane, and mapping system components. > • Multicast Support: LISP support for multicast environments has a > growing number of use cases. Support for multicast is needed in order to > achieve scalability. The current documents [Ref to experimental multicast > RFCs] should be merged and published as Standard Track. I think the smaller work items that we can knock out should be in Part 1 like geo-coordinates and name-encoding. And there is no mention of VPN and TE support. It needs to go in somewhere. > Proposed Charter: Work Items Part 2 > • Standard Track Documents: The core specifications of LISP have been > published as “Standard Track” [references]. The WG will continue the work of > moving select specifications to “Standard Track”. > • Mobility: Some LISP deployment scenarios include mobile nodes (in > mobile environments) or Virtual Machines (VMs in data centers), hence, > support needs to be provided in order to achieve seamless connectivity. > • Privacy and Security: The WG will work on topics of EID anonymity, VPN > segmentation leveraging on the Instance ID, and traffic anonymization. The > reuse of existing mechanisms will be prioritized. I would not call VPN segmentation as security. I view it more as topological member grouping. > • LISP Applicability: In time, LISP has proved to be a very flexible > protocol that can be used in various use-cases not even considered during its > design phase. RFC 7215, while remaining a good source of information, covers > one single use case, which is not anymore the main LISP application scenario. > The LISP WG will document LISP deployments for most recent and relevant > use-cases so as to update RFC 7215. > Proposed Charter: Tentative Milestones > • November 2023: Submit a LISP YANG document to the IESG for consideration > • March 2024: Submit a LISP NAT Traversal document to the IESG for > consideration > • June 2024: Submit 8111bis to the IESG for consideration > • June 2024 : Submit LISP geo-coordinates for consideration This, with name-encoding, can get done sooner. We just have to push harder. > • November 2024: Submit merged Multicast document to the IESG for > consideration Note, from the previous email you referred to "underlay-multicast-trees". That document has changed its name to reflect what it really is designing, its titled draft-vdas-lisp-group-mapping-00. > • March 2025: Submit 6832bis pXTRs to the IESG for consideration > • June 2025: Submit merged LCAFbis to the IESG for considerations > • November 2025: Submit LISP Mobile Node to the IESG for considerations > • March 2026: Submit LISP Applicability document to the IESG for > considerations > • November 2026: Wrap-Up or recharter There should be some mention on what to do with the use-case documents. Either a spin-off operational working group, or publish as Informational or something else. And the same for draft-farinacci-lisp-decent, which is the only mapping database document on the table. I think its more than a operational use-case since there is design mechanisms and algorithms in the specification. Dino > On Oct 3, 2023, at 5:14 PM, Alvaro Retana wrote: > > Hi! > > In general, I like the charter. However, I have some questions/comments: > > (1) What’s the difference between the work items in
Re: [lisp] Proposed WG Charter on GitHub
> 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 > preferable to have several docs. It would be great to hear feedback from the > WG. I propose (and prefer) seperate docs since RFC6831 is really large and details the interaction of LISP with PIM used in the underlay. And RFC8378 focuses solely on an unicast underlay. And of course draft-vda-lisp-underlay-multicast-trees allows you to have a mix of unicast and multicast RLOC mappings which both RFC6831 and RFC8378 use. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] IETF 117 Preliminary Agenda: Call for agenda items
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 24th July. > > Please send an email to the chairs if you want a presentation slot. > > Ciao > > L. > > > P.S. Note that this is the preliminary agenda and subject to changes. > > >> Begin forwarded message: >> >> From: IETF Agenda >> Subject: IETF 117 Preliminary Agenda >> Date: 23 June 2023 at 23:36:36 CEST >> To: "IETF Announcement List" >> Cc: i...@ietf.org, 117...@ietf.org >> Reply-To: supp...@ietf.org >> >> IETF 117 >> San Francisco, CA, USA >> July 22-28, 2023 >> Hosted By: NOKIA >> >> >> The IETF 117 Preliminary Agenda has been posted. The final agenda will be >> published on Friday, June 30, 2023. >> >> https://datatracker.ietf.org/meeting/117/agenda.html >> https://datatracker.ietf.org/meeting/117/agenda.txt >> >> The preliminary agenda includes all planned WG, RG, and BoF sessions. >> Information about side meetings will be available when the final agenda is >> posted. >> >> IETF 117 Information: https://www.ietf.org/how/meetings/117/ >> Register online at: https://registration.ietf.org/117/ >> >> Don’t forget to register for these exciting IETF 117 events! >> >> >> Social Event >> >> The San Francisco Museum of Modern Art is an internationally recognized >> collection of modern and contemporary art. This collection includes >> masterworks and experimental pieces from SFMOMA’s collection of painting and >> sculpture. >> >> There will be a wide array of food and beverages to suit all tastes and will >> include vegetarian and vegan options. Transportation will not be provided as >> the venue is a short 15 minute walk from the headquarter hotel (Hilton Union >> Square). >> >> - Date: Tuesday, July 25 >> - Start/End Times: 19:00 – 22:30 (Galleries close at 22:00) >> - Cost per ticket: $30 per ticket, limit of two tickets per attendee. >> - Children under 12 allowed for free >> >> More information: >> https://www.ietf.org/how/meetings/117/social/ >> >> >> Hackathon >> >> Onsite signup: https://registration.ietf.org/117/new/hackathon_onsite/ >> Remote signup: https://registration.ietf.org/117/new/hackathon_remote/ >> More information: >> https://www.ietf.org/how/runningcode/hackathons/117-hackathon/ >> Keep up to date by subscribing to: >> https://www.ietf.org/mailman/listinfo/hackathon >> >> >> Code Sprint >> >> More information and signups: https://notes.ietf.org/notes-ietf-117-tools# >> >> ___ >> IETF-Announce mailing list >> ietf-annou...@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
> "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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
>>> >>> 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 LCAF. Well to be specific, if you put a dist-name with the RLOC it is encoded as an AFI-list LCAF. But I know what you mean. You are proposing/considering a new LCAF type that identifies an RTR. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
I can add that text. Dino > On May 24, 2023, at 11:38 AM, Joel Halpern wrote: > > If you want to start the draft by saying "this describes a shortcut we took, > which works among consenting parties when no one else is using the particular > values in nay other way, but we 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/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 that doesn't violate the spec. >>> claiming that this alternative meaning is not a violation is quite a >>> stretch. >> As an implementor, it was convienent. I'm not saying anything more than >> that. I should have used an alternative mechanism. >> >>>>> - What about backward compatibility? If we allow overloading, there is no >>>>> way to understand whether a value indicates a “true” priority or >>>>> something else, different implementations may interpret the value in >>>>> different ways with unpredictable results. >>>> It always means a true value from an xTR point of view. >>> It is the true value because you said so. The important point however >>> is that you decclare that otehr nodes can tell that the advertiser is an >>> RTR from the priority. That is adding additional inappropriate, and >>> overloading meaning to the priority. >> I don't know what you mean. The map-server will return RLOCs with >> priorities. The ITR uses them according the spec. There isn't anything more >> complciated than that. >> >> I do not declare that from an ITR point of view. It is true from an ETR >> point of view. >> >> I'm trying to provide clarity and details so the working group understands >> how it works not the motivation for using the solution or why it was chosen. >> >> Dino >> >> >> ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
> 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 that doesn't violate the spec. > claiming that this alternative meaning is not a violation is quite a > stretch. As an implementor, it was convienent. I'm not saying anything more than that. I should have used an alternative mechanism. >> >>> - What about backward compatibility? If we allow overloading, there is no >>> way to understand whether a value indicates a “true” priority or something >>> else, different implementations may interpret the value in different ways >>> with unpredictable results. >> It always means a true value from an xTR point of view. > > It is the true value because you said so. The important point however > is that you decclare that otehr nodes can tell that the advertiser is an RTR > from the priority. That is adding additional inappropriate, and overloading > meaning to the priority. I don't know what you mean. The map-server will return RLOCs with priorities. The ITR uses them according the spec. There isn't anything more complciated than that. I do not declare that from an ITR point of view. It is true from an ETR point of view. I'm trying to provide clarity and details so the working group understands how it works not the motivation for using the solution or why it was chosen. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
> 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 whether a value indicates a “true” priority or something else, > different implementations may interpret the value in different ways with > unpredictable results. It always means a true value from an xTR point of view. > - What about weight? In the lispers.net NAT traversal it is used as defined > in the main specs, but this means that all RTR have the same priority all the > time. And what if a future value will indicate not to use weight? Or use it > in a different way? This solution does not violate the LISP spec on how ITRs/RTRs use priorities and weights. > - With the above we end up having RLOCs priorities that can be priority or > something else. In this latter case weight can or cannot be meaningful (or > even be something else altogether). Architecturally speaking it looks to me > less clean. This is simply not true. I think you are overstating the problem. > 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. > The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved > bits. One can be allocated to indicate whether the RLOC address belongs to an > RTR. That could be too specific to this use-case. What an ETR needs to know is if it should tag RLOCs it gets back from the map-server in Info-Reply messages with this bit. It actually could not tag it at all since the map-servers know the addresses of RTR RLOCs when they advertise them. But that means all map-servers need to have the same info and there is configuration coordination required. > A side benefit of this choice would be that older implementations will just > ignore the bit, hence taking no action, rather than interpreting the bit in a > different way. Looks like a safer situation to me. You can even use a whole > new type, so that an implementation either knows how to handle it or does > nothing at all. No that won't be the case. The way it works is that the RTR will give an RLOC-set to the ITR. So the ITR doesn't know if an RLOC is an ETR RTR pETR, etc. But the ETR side registeres the RTR RLOCs with 254. That is what is implemented today. If the ETR DOES NOT do this the map-server could figure it out on its own (as I mention above). Dino > > Thoughts from the WG folks? > > Ciao > > L. > > >> >> Note this is only how the map-server operates. So existing xTRs will get >> back whatever the map-server decides. So if you are not an RTR (that must be >> configured in the said map-server) you will get back an RTR RLOC that an xTR >> will happily encapsulate to. That is, it works with existing xTRs that don't >> know anything about NAT-traversal. >> >> This implementation has interoperated with other implementations, but we >> don't claim anything in the draft. And existing xTRs can *receive* packets >> without following the control-plane procedures from the draft. We >> demostrated this with OOR by doing gleaning on the RTR. >> >> I have videos demostrating this for unicast and multicast and can send >> pointers if people are interested. >> >> Dino >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
> 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 good idea, > but publishing such "squatting" in an RFC doesn't seem like a good idea. So > how to move forward? I'm seeking pragmatic answers to that question. That is not true. A value of 254 means that the RLOC has a pretty low priority in usage. That is, if an ITR receives an RLOC-set with 254 in it, it will use it. Note, a lispers.net map-server will return ONLY 254 RLOCs to an ITR in which the ITR uses spec rules to decide which one to use. Also note, the WG cannot say how priorities are used. It is a deployment and policy issue for the LISP overlay operater. All the spec says is that 1 takes priority over 255 in selecting which RLOCs are used for encapsulation. The implementation is really NOT violating the spec and the decision of the extra semantic meaning on 254 is only in a lispers.net map-server. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
> 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 reporting/documenting how it is used. Note this is only how the map-server operates. So existing xTRs will get back whatever the map-server decides. So if you are not an RTR (that must be configured in the said map-server) you will get back an RTR RLOC that an xTR will happily encapsulate to. That is, it works with existing xTRs that don't know anything about NAT-traversal. This implementation has interoperated with other implementations, but we don't claim anything in the draft. And existing xTRs can *receive* packets without following the control-plane procedures from the draft. We demostrated this with OOR by doing gleaning on the RTR. I have videos demostrating this for unicast and multicast and can send pointers if people are interested. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] On the use of priority associated to RLOCs
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) When an RTR wants to encapsulate to this xTR, it CAN do so with the global RLOC. (4) So when either the ITR or RTR do a Map-Request lookup, the map-server returns a PARTIAL RLOC-set to the requester. That is, it returns the global RLOC(s) to the RTR and the RTR RLOC(s) to the ITR. For the map-server to know in an RLOC-set which RLOCs belong to RTRs, they are registered with RLOC priority 254. Dino > On May 23, 2023, at 7:07 AM, Luigi Iannone wrote: > > Hi All, > > > TL;DR: Should the priority associated to RLOCs be used to indicate something > else? > > Long Version: > > As you may (or may not) know Dino submitted the lispers.net NAT traversal > solution > (https://datatracker.ietf.org/doc/draft-farinacci-lisp-lispers-net-nat/ ) for > publication on the Independent Stream > (https://www.rfc-editor.org/about/independent/). > > Current ISE Editor is Eliot Lear (well known by old lispers like me ;-) ) > > During the review of the document an interesting question came up: > > Lispers.net NAT traversal uses priority 254 to indicate that the RLOC belongs > to a RTR. > > No text in old and new specs suggest a usage of the priority to deliver > something different than the priority itself. > Even the value 255 is related to priority: do not use this RLOC = no priority. > > It goes without saying that there is no IANA registry about special value of > priority associated to RLOCs. > > At the same time there is no text that explicitly states “priority indicates > only the priority and CANNOT be used for something else”. > > So the question is: Should we (the WG) consider that priorities can be used > to indicate something different from priority? > > If not: we may want to write it down somewhere. > > If yes: Well…. This deserves a longer discussion (may be to be included in > the new charter…). > > Thoughts ? > > Ciao > > Luigi >___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] Fwd: I-D Action: draft-vdas-lisp-group-mapping-00.txt
FYI. Dino > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: I-D Action: draft-vdas-lisp-group-mapping-00.txt > Date: April 24, 2023 at 8:36:35 AM PDT > To: > Reply-To: internet-dra...@ietf.org > > > A New Internet-Draft is available from 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 > Filename: draft-vdas-lisp-group-mapping-00.txt > Pages : 9 > Date: 2023-04-24 > > Abstract: > This draft augments LISP [RFC9300] multicast functionality described > in [RFC6831] and [RFC8378] to support the mapping of overlay group > addresses to underlay RLOC addresses. This draft defines a many-to- > 1, 1-to-many, and many-to-many relationship between multicast EIDs > and the Replication List Entries (RLEs) RLOC records they map to. > The mechanisms in this draft allow a multicast LISP overlay to run > over a mixed underlay of unicast and/or multicast packet forwarding > functionality. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-vdas-lisp-group-mapping/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-vdas-lisp-group-mapping-00 > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Comments to draft-ietf-lisp-te-12
> 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 in the LISP overlay case. > *header*. Is the header consisted of outer IP header and LISP header, or just > IP header (assuming the IP underlay network)? I want to make it clear whether > the writing of 'recursive' means utilizing the TE capabilities of underlay > network. (referring to the second example of recursion in 5.2) The recursive header means this: (1) First inner header with EIDs is constructed by the host. (2) Outer header with RLOCs is constructed by the first ITR/RTR/PITR that gets the EID packet. (3) A second outer header with RLOCs is constructed by any ITR/RTR/PITR that is on path of the RLOC packet. And (3) is only performed, if that xTR is configured to add a header. > • If yes, I would argue that Section 5.2 in RFC 9300 describes the > IPv6-in-IPv6 header format but it didn’t include the extensions of IPv6 > header. Consequently, underlay TE is not available in this case since segment > routing header(RFC 8754) requires the use of extension header. (Unless > another IP header that involves extension header is prepended) Extension headers are not used in general. If, for instance, an ITR/RTR/PITR wanted to add an SRH, a draft would need to be written to say exactly what they do when they want to use an underlay with such capability. But segment-route controls the path the ITR choose FOR THE underlay and not the encapsulation path (overlay path) which LISP-TE specs out. > • If no, it says that LISP has to prepend more headers (IP header or LISP > header, or both of them). Obviously, it could be not efficient enough. In > this case, why not make it a more elegant way, for example, enabling LISP > header to carry the RLOC record. I am not following your suggestion. The LISP header has specific features like lisp-crypto, nonce-echoing, map-versioning, vpn-identificaion which are relevant to handling the packet and not what header is prepended to the packet. That is a later step after LISP header is prepended. Note when you prepend an outer IPv4 or IPv6 header in front of a LISP header, it means that header has RLOC addresses in it. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-jain-lisp-site-external-connectivity-08.txt
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 > Authors : Prakash Jain > Victor Moreno > Sanjay Hooda > Filename: draft-jain-lisp-site-external-connectivity-08.txt > Pages : 7 > Date: 2023-03-27 > > Abstract: > This draft defines how to register/retrieve pETR mapping information > in LISP when the destination is not registered/known to the local > site and its mapping system (e.g. the destination is an internet or > external site destination). > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-jain-lisp-site-external-connectivity-08 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-jain-lisp-site-external-connectivity-08 > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-jain-lisp-site-external-connectivity comments/discussion
> 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 we are open > to discuss and conclude it either way for the best solution. Would like to > hear if any other opinion on this. There must have been a typo here. PubSub should absolutely be in the spec. I was referring to SMRs, it is the mechanisms that is slow and uses more network bandwidth than PubSub. > >> • (Padma): Elaborate of how pETR map-reply would be installed/used at ITR >> (so that no forwarding inefficiencies to send every packet to pxTR) >> (Authors): ITR would encapsulate the packets to the pETRs for only non-EIDs >> destinations (for both “EIDs not registered with the Mapping System, or >> simply are not known" as mentioned in the draft) since more specific entries >> would already be present for known overlay subnets/EID-block-range at ITR to >> generate map-request. > > EIDs not registered are not non-EIDs. Destinations that are unknown are > non-EIDs. Your parantetical comment is misleading. Well EIDs not registered could be a part of an EID-prefix that IS registered. So the best way to describe this is, if a destination IP address from a packet header is looked up, and a negative map-reply is returned, the ITR for sure knows the destination address IS NOT an EID. But the 2 bullets below cover all 3 situations (an EID destination, an EID not registered yet, and a non-EID). > PJ>>> Ok, will clarify. Parenthetical comment is the text from the draft for > the EIDs not registered to the mapping system which can be encapsulated to > pETRs (implementation can still choose what to encapsulate at ITR), its not > the definition of 'non-EIDs'. > > What we agreed on was this: > > (1) Define an EID-block. Destinations that match this block are map-requested. > (2) Destinations not in an EID-block are non-EIDs and are encapsulated to the > pETR > PJ>>> Correct. Good. That is the algorithm and it works. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished
> 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 cases, or address them. Agree, just having basic LISP NAT-traversal standardized, or even just documented, should be our key goal. Or it limits LISP deployments to virually no where. Meaning, just within firewall/security domains. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished
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 RTRs. Some time ago I proposed > a possible solution but I believe we need to think a little more to find a > more optimal solution. > Albert López > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished
> 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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished
>> 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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Rechartering Thread 2: From Experimental to ST: these are a bunch of RFC that may be considered
> 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 deployment experience), namely: > > RFC 6832: Interworking between Locator/ID Separation Protocol (LISP) and > Non-LISP Sites > RFC 8060: LISP Canonical Address Format (LCAF) [This is largely used and may > be merged with 9306] > RFC 8111: Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) > [The only scalable Mapping System so far…..] Agree. > Multicast can be another one work item. > RFC 6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments > RFC 8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast The new draft that Prasad submitted this week makes it a trio with the above to. It addresses how to mix the functionality of 6831 and 8378 when there is a mix of native multicast and non-native multicast in the underlay. Dino > > Please send us back your thoughts. > > > Padma and Luigi > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished
> 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 lot in LISP deployments, so draft-ietf-lisp-vpn. Alternative Mapping System Design is part of the charter and the only draft that is pending is draft-farinacci-lisp-decent but not sure this needs to be standardized. And we need to decide the outcome of draft-ietf-lisp-te and control-plane security such as draft-ietf-lisp-ecdsa-auth and draft-ietf-eid-anonymity. I'm not sure they need to be standards track. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Fwd: lisp - Requested session has been scheduled for IETF 116
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 than > next Tuesday (14th March). > > Ciao > > L. > > >> Begin forwarded message: >> >> From: "\"IETF Secretariat\"" >> Subject: lisp - Requested session has been scheduled for IETF 116 >> Date: 4 March 2023 at 00:06:29 CET >> To: , >> Cc: aretana.i...@gmail.com, lisp@ietf.org >> Resent-From: >> Resent-To: padma.i...@gmail.com, g...@gigix.net, na...@cisco.com >> >> Dear Luigi Iannone, >> >> The session(s) that you have requested have been scheduled. >> Below is the scheduled session information followed by >> the original request. >> >> >>lisp Session 1 (2:00 requested) >>Tuesday, 28 March 2023, Session II 0400-0600 >>Room Name: G412-G413 size: 100 >>- >> >> >> iCalendar: https://datatracker.ietf.org/meeting/116/sessions/lisp.ics >> >> Request Information: >> >> >> - >> Working Group Name: Locator/ID Separation Protocol >> Area Name: Routing Area >> Session Requester: Luigi Iannone >> >> >> Number of Sessions: 1 >> Length of Session(s): >> Number of Attendees: 30 >> Conflicts to Avoid: >> >> >> >> >> Participants who must be present: >> Alberto Rodriguez-Natal >> Luigi Iannone >> Padma Pillay-Esnault >> >> Resources Requested: >> >> Special Requests: >> >> - >> >> > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-pubsub-13.txt
But the references you provide, suggest that configuration information is required so the verification can be performed. The text in the PubSub document is just too general. I would add, that verification is done through configuration. Dino > On Feb 20, 2023, at 10:37 AM, Alberto Rodriguez-Natal (natal) > wrote: > > Dino, > It is not the intention of the specification to recommend or to prescribe > how deployments will enforce the recommendations in 1.1. Rather than focus on > implementation examples, the reader should focus on the recommendations > themselves. Please also consider that while the implementation of the > recommendations in Section 1.1 of PubSub is left out of scope, these > recommendations are in the same “order of magnitude” of similar out-of-scope > recommendations/assumptions made on the main LISP specs, some examples: > “The Mapping System is aware of which EIDs an ETR can advertise. How those > keys and mappings are established is out of scope for this document.” – RFC > 9301, Section 9 > “[…] a Map-Server MUST verify that all EID-Prefixes registered by an ETR > match the configuration stored on the Map-Server.” – RFC 9301, Section 9 > “Similarly, Map-Register security, including the right for a LISP entity to > register an EID-Prefix or to claim presence at an RLOC, is out of the scope > of LISP-SEC.” – RFC 9303, Section 7.1 > “The Mapping System is secure and trusted, and for the purpose of these > security considerations, the Mapping System is considered as one trusted > element. ” – RFC 9301, Section 9 > With that perspective, we believe the recommendations made for PubSub do not > depart too much from the tone set by the general LISP > 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: > 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 the Map-Server know which are legit > Map-Resolvers? > This text is hand-waving with no support text to say how it does it. > Dino > > > On Feb 15, 2023, at 2:47 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol WG of the > IETF. > >Title : Publish/Subscribe Functionality for the Locator/ID > Separation Protocol (LISP) >Authors : Alberto Rodriguez-Natal > Vina Ermagan > Albert Cabellos > Sharon Barkai > Mohamed Boucadair > Filename: draft-ietf-lisp-pubsub-13.txt > Pages : 21 > Date: 2023-02-15 > > Abstract: > This document specifies an extension to the request/reply based > Locator/ID Separation Protocol (LISP) control plane to enable > Publish/Subscribe (PubSub) operation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-13 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-13 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-pubsub-13.txt
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 the Map-Server know which are legit Map-Resolvers? This text is hand-waving with no support text to say how it does it. Dino > On Feb 15, 2023, at 2:47 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol WG of the > IETF. > >Title : Publish/Subscribe Functionality for the Locator/ID > Separation Protocol (LISP) >Authors : Alberto Rodriguez-Natal > Vina Ermagan > Albert Cabellos > Sharon Barkai > Mohamed Boucadair > Filename: draft-ietf-lisp-pubsub-13.txt > Pages : 21 > Date: 2023-02-15 > > Abstract: > This document specifies an extension to the request/reply based > Locator/ID Separation Protocol (LISP) control plane to enable > Publish/Subscribe (PubSub) operation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-13 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-13 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10
> 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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10
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 wrote: Given that a lot of the use cases have a lot of legitimate users, I think magnus concern is reasonable, but I am willing to settle for less. If I am reading things right, the xTR<->Map_Resolver exchanges for pub-sub SHOULD use LISP-SEC. And the Map-Resolver<->Map Server exchanges should magically know that the Map Resolvers are doing so? The SHOULD needs some explanation as to when it is okay not to, or else it ought to be upgraded to a MUST. The Map Server requirement seems like it would benefit from some explanation as to how this knowledge would exist. Yours, Joel PS: If LISP Sec can be used along the lines Dino indicated, taht would be a nice way to combine some of the protections and better address the issues. On 2/15/2023 1:36 PM, mohamed.boucad...@orange.com wrote: Hi Joel, The proposal is not to restrict the usage of PubSub to “limited domains” as per RFC8799. Please refer to https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to see the text we are planning to include as applicability scope. I think this is a reasonable suggestion especially that we want to leverage 9301/9303. Thank you. Cheers, Med De : Joel Halpern Envoyé : mercredi 15 février 2023 17:32 À : BOUCADAIR Mohamed INNOV/NET ; Magnus Westerlund ; Alberto Rodriguez-Natal (natal) ; tsv-...@ietf.org Cc : draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; lisp@ietf.org Objet : Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10 Hmmm. Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub mechanism do not seem to be limited enough to qualify for being a limited domain. On the other hand, the general idea of the DDOS prevention mechanism (modeled loosely on the prevention of TCP State attacks) seems valuable and easy to add. If a Map Server serving a broad community gets a pub-sub subscription request, and it is under any significant load, it can 1) craft a security token hashing the request, the current time, and a private key (and whatever else security says is needed 2) Sending the token and time back to the requestor in an error 3) When the requestor sends back the request, it includes the timestamp and token. The server only processes the request if the information validates. This validates that the response actually went to the requestor, and was a real request. Yes, it slightly slows down the pub-sub registration under load. I don't know if I caught all of Magnus' issue, but this would seem a good thing to do. Yours, Joel On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote: Hi Magnus, Thank you for the follow-up. First, your observation on the verification procedure at the Map-Server is fair. We have documented the issue in draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret and discussed the alternative to strengthen the verification based on the timestamp but we had also the constraint to navigate in the LISP environment where LISP-SEC messages are not timestamped. We think that the procedure in the draft is a good compromise of what we can achieve given that constraint. FWIW, the full reasoning is available at: timestamp to prevent replay attacks · Issue #1 · boucadair/draft-ietf-lisp-pubsub (github.com). Second, I support your proposal to add an applicability statement to the document. The content will be basically
Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10
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. The big benefit is that the map-server doesn't have to hold more client state and can scale better, as Magnus referred to. Dino > On Feb 15, 2023, at 8:32 AM, Joel Halpern wrote: > > Hmmm. > > Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub > mechanism do not seem to be limited enough to qualify for being a limited > domain. > > On the other hand, the general idea of the DDOS prevention mechanism (modeled > loosely on the prevention of TCP State attacks) seems valuable and easy to > add. If a Map Server serving a broad community gets a pub-sub subscription > request, and it is under any significant load, it can > > 1) craft a security token hashing the request, the current time, and a > private key (and whatever else security says is needed > > 2) Sending the token and time back to the requestor in an error > > 3) When the requestor sends back the request, it includes the timestamp and > token. The server only processes the request if the information validates. > > This validates that the response actually went to the requestor, and was a > real request. Yes, it slightly slows down the pub-sub registration under > load. > > I don't know if I caught all of Magnus' issue, but this would seem a good > thing to do. > > Yours, > > Joel > > On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote: >> Hi Magnus, >> >> Thank you for the follow-up. >> >> First, your observation on the verification procedure at the Map-Server is >> fair. We have documented the issue in >> draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret >> and discussed the alternative to strengthen the verification based on the >> timestamp but we had also the constraint to navigate in the LISP environment >> where LISP-SEC messages are not timestamped. We think that the procedure in >> the draft is a good compromise of what we can achieve given that constraint. >> FWIW, the full reasoning is available at: timestamp to prevent replay >> attacks · Issue #1 · boucadair/draft-ietf-lisp-pubsub (github.com). >> >> Second, I support your proposal to add an applicability statement to the >> document. The content will be basically moving (and adjusting the language) >> the following text in Section 7 to that section: >> >> OLD: >>It is also RECOMMENDED that the Map-Resolver >>verifies that the xTR is allowed to use PubSub and to use the xTR-ID >>and ITR-RLOCs included in the Map-Request. Map-Servers SHOULD be >>configured to only accept subscription requests from Map-Resolvers >>that verify Map-Requests as previously described. >> >> I let Alberto further comment as appropriate. >> >> Cheers, >> Med >> >> De : Magnus Westerlund >> Envoyé : mercredi 15 février 2023 08:33 >> À : Alberto Rodriguez-Natal (natal) ; BOUCADAIR Mohamed >> INNOV/NET ; tsv-...@ietf.org >> Cc : draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; lisp@ietf.org >> Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10 >> >> Hi, >> >> Thanks for the many improvements and I think this is likely safe enough for >> limited deployments when the Map-Server are not open to any xTR to send >> requests. I don’t think this is safe enough for general Internet usage for >> two reasons. First, the verification procedure forces the MAP-Server to hold >> state rather than the requestor and the messages only. Secondly, a lot of >> the security procedures are only RECOMMEND/SHOULD. For an open Internet I >> think a more tightly defined security mechanisms and protection profile >> should be specified. >> >> Thus, my recommendation would be to add an applicability statement to the >> document making clear that this is intended for the deployments with more >> limited access to Map-Servers than what an open internet deployment >> provides. >> >> Cheers >> >> Magnus Westerlund >> >> From: Alberto Rodriguez-Natal (natal) >> Date: Monday, 13 February 2023 at 20:26 >> To: mohamed.boucad...@orange.com , Magnus >> Westerlund , tsv-...@ietf.org >> >> Cc: draft-ietf-lisp-pubsub@ietf.org >> , last-c...@ietf.org >> , lisp@ietf.org >> Subject: Re: Tsvart last call review of draft-ietf-lisp-pubsub-10 >> >> Hi Magnus, >> >> Just FYI, we have just published a new revision that further polishes some >> details. >> >> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-12 >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-12 >> >> Thanks! >> Alberto >> >> From: mohamed.boucad...@orange.com >> Date: Friday, February 10, 2023 at 3:55 PM >> To: Magnus Westerlund , Alberto >> Rodriguez-Natal (natal) ,
Re: [lisp] Erik Kline's No Objection on draft-ietf-lisp-pubsub-11: (with COMMENT)
Okay I see the confusion and how this could be misleading. I’m not sure how to fix this editorially.The 2 fields are in a “Map-Reply Record” which was only in a Map-Register. If a Map-Request would want to supply mapping entry, it would include a Map-Reply Record. But before pubsub was spec’ed there would be no way to encode the 2 new fields because the I-bit was not specified. Since the pubsub spec introduces the I-bit the 2 fields can be included and needed for the new protocol operation sped ‘ed in the pubsub draft. A possible fix is to have pubsub refer to 9301, section 5.6 but would 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 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, those are existing fields in the Map-Register message (and not the Mal-Request message). I'm referring to the xTR-ID field and Site-ID field, both of which appear to be described as being "added to the Map-Request message defined in Section 5.2 of [RFC9301]", per Section 4 of the draft. ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Erik Kline's No Objection on draft-ietf-lisp-pubsub-11: (with COMMENT)
>> 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, those are existing fields in the Map-Register message (and not the Mal-Request message). Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Erik Kline's No Objection on draft-ietf-lisp-pubsub-11: (with COMMENT)
> 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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [IANA #1264435] expert review for draft-ietf-lisp-pubsub (lisp-parameters)
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 registration in draft-ietf-lisp-pubsub > for us? Please see: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/ > > The due date is February 1st, 2023. > > If this is OK, when the IESG approves the document for publication, we'll > make the registration at > > https://www.iana.org/assignments/lisp-parameters/lisp-parameters > > We'll wait for both reviewers to respond unless you tell us otherwise. > > With thanks, > > David Dong > IANA Services Specialist ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-jain-lisp-site-external-connectivity comments/discussion
> 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 Pubsub and then in a trailing paragraph indicate “If pubsub is not available in the mapping system, then use the procedures from RFC 9301 for updating map-caches”. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-jain-lisp-site-external-connectivity comments/discussion
> • (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 messages would be sent to subscribed ITRs as per > the PubSub specification. With pub-sub, later option could be preferred as it > would be faster. 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. > • (Padma): Elaborate of how pETR map-reply would be installed/used at > ITR (so that no forwarding inefficiencies to send every packet to pxTR) > (Authors): ITR would encapsulate the packets to the pETRs for only non-EIDs > destinations (for both “EIDs not registered with the Mapping System, or > simply are not known" as mentioned in the draft) since more specific entries > would already be present for known overlay subnets/EID-block-range at ITR to > generate map-request. EIDs not registered are not non-EIDs. Destinations that are unknown are non-EIDs. Your parantetical comment is misleading. What we agreed on was this: (1) Define an EID-block. Destinations that match this block are map-requested. (2) Destinations not in an EID-block are non-EIDs and are encapsulated to the pETR. How do you implement this, really simple: (1) You have a default map-cache entry with RLOCs of the pETRs. Once you determine their RLOCs, the ITR installs the default map-cache entry. So non-EID destinations will match this entry. (2) You put the EID-block as an EID-prefix, at configuraiton time, static in the map-cache, that when matched, sends a map-request. So EID destinatinos will match this entry. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] Fwd: I-D Action: draft-ietf-lisp-geo-01.txt
This update reflects Luigi's comments. The only outstanding issue I think we have is if RFC8060 should be updated (I think it should) to reflect the packet format changes. Dino > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-geo-01.txt > Date: December 12, 2022 at 12:26:39 PM PST > To: > Cc: lisp@ietf.org > Reply-To: lisp@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol 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 Geo-Coordinates can be used in the LISP > Architecture and Protocols. Some use-cases can be geo-fencing and > physically locating objects. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-geo/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-geo-01 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-geo-01 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Review for LISP Geo-Coordinate Use-Cases
> > 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 since so much time has passed. > > Indeed it has been quite some time…. > > If you look Section 4.3 of RFC 8060 you can see Type 5 LCAF Format that is > completely incompatible with the specs in this document. We need to update RFC 8060 so the format in the geo draft matches and points to this use-case draft. That is what we have done with the other LCAF types. So we just need to be consistent. > What about asking for type 15 and name it “extended Geo-coordinates”? There is no point to have 2 code points for Geo-Coordinates. Want me to start on a 8060bis document? Dino > > Ciao > > L. > > > >> >> So we do not need a new type. >> >> Dino >> >>> On Dec 9, 2022, at 6:38 AM, Luigi Iannone wrote: >>> >>> Hi Dino, >>> >>> I reviewed the lisp-geo document. My comments inline. >>> >>> Ciao >>> >>> L. >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> Network Working Group D. Farinacci >>>> Internet-Draft lispers.net >>>> Intended status: Experimental 23 November 2022 >>>> Expires: 27 May 2023 >>>> >>>> >>>> LISP Geo-Coordinate Use-Cases >>>> draft-ietf-lisp-geo-00 >>>> >>>> Abstract >>>> >>>> This draft describes how Geo-Coordinates can be used in the LISP >>>> Architecture and Protocols. >>>> >>> >>> Would be good to add more word. The document does 2 things: propose uses >>> cases, define geo coordinates encoding. >>> >>> >>>> Status of This Memo >>>> >>>> This Internet-Draft is submitted in full conformance with the >>>> provisions of BCP 78 and BCP 79. >>>> >>>> Internet-Drafts are working documents of the Internet Engineering >>>> Task Force (IETF). Note that other groups may also distribute >>>> working documents as Internet-Drafts. The list of current Internet- >>>> Drafts is at https://datatracker.ietf.org/drafts/current/. >>>> >>>> Internet-Drafts are draft documents valid for a maximum of six months >>>> and may be updated, replaced, or obsoleted by other documents at any >>>> time. It is inappropriate to use Internet-Drafts as reference >>>> material or to cite them other than as "work in progress." >>>> >>>> This Internet-Draft will expire on 27 May 2023. >>>> >>>> Copyright Notice >>>> >>>> Copyright (c) 2022 IETF Trust and the persons identified as the >>>> document authors. All rights reserved. >>>> >>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>> Provisions Relating to IETF Documents (https://trustee.ietf.org/ >>>> license-info) in effect on the date of publication of this document. >>>> Please review these documents carefully, as they describe your rights >>>> and restrictions with respect to this document. Code Components >>>> extracted from this document must include Revised BSD License text as >>>> described in Section 4.e of the Trust Legal Provisions and are >>>> provided without warranty as described in the Revised BSD License. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Farinacci Expires 27 May 2023 [Page 1] >>>> Internet-DraftLISP Geo-Coordinate Use-CasesNovember 2022 >>>> >>>> >>>> Table of Contents >>>> >>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >>>> 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 >>>> 3. Geo-Points in RLOC-records . . . . . . . . . . . . . . . . . 3 >>>> 4. Geo-Prefixes in EID-records and RLOC-records . . . . . . . . 3 >>>> 5. Geo-Prefix and Geo-Point Encodings . . . . . . .
Re: [lisp] Review for LISP Geo-Coordinate Use-Cases
gt;> >> >> >> >> Farinacci Expires 27 May 2023 [Page 8] >> Internet-DraftLISP Geo-Coordinate Use-CasesNovember 2022 >> >> >> [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., >> Tschofenig, H., and H. Schulzrinne, "An Architecture for >> Location and Location Privacy in Internet Applications", >> BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, >> <https://www.rfc-editor.org/info/rfc6280>. >> >> [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., >> Morris, J., Hansen, M., and R. Smith, "Privacy >> Considerations for Internet Protocols", RFC 6973, >> DOI 10.17487/RFC6973, July 2013, >> <https://www.rfc-editor.org/info/rfc6973>. >> >> [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical >> Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, >> February 2017, <https://www.rfc-editor.org/info/rfc8060>. >> >> [RFC9300] 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>. >> >> 9.2. Informative References >> >> [AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY >> NUMBERS http://www.iana.org/assignments/address-family- >> numbers/address-family-numbers.xhtml?, February 2007. >> >> [I-D.acee-ospf-geo-location] >> Lindem, A., Shen, N., and E. Chen, "OSPF Extensions for >> Advertising/Signaling Geo Location Information", Work in >> Progress, Internet-Draft, draft-acee-ospf-geo-location-05, >> 18 October 2017, <https://www.ietf.org/archive/id/draft- >> acee-ospf-geo-location-05.txt>. >> >> [I-D.chen-idr-geo-coordinates] >> Chen, E., Shen, N., and R. Raszuk, "Carrying Geo >> Coordinates in BGP", Work in Progress, Internet-Draft, >> draft-chen-idr-geo-coordinates-02, 31 October 2016, >> <https://www.ietf.org/archive/id/draft-chen-idr-geo- >> coordinates-02.txt>. >> >> [I-D.ietf-lisp-ecdsa-auth] >> Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA >> Authentication and Authorization", Work in Progress, >> Internet-Draft, draft-ietf-lisp-ecdsa-auth-09, 11 >> September 2022, <https://www.ietf.org/archive/id/draft- >> ietf-lisp-ecdsa-auth-09.txt>. >> >> >> >> >> Farinacci Expires 27 May 2023 [Page 9] >> Internet-DraftLISP Geo-Coordinate Use-CasesNovember 2022 >> >> >> [I-D.ietf-lisp-name-encoding] >> Farinacci, D., "LISP Distinguished Name Encoding", Work in >> Progress, Internet-Draft, draft-ietf-lisp-name-encoding- >> 00, 6 September 2022, <https://www.ietf.org/archive/id/ >> draft-ietf-lisp-name-encoding-00.txt>. >> >> [I-D.ietf-lisp-sec] >> Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, >> "LISP-Security (LISP-SEC)", Work in Progress, Internet- >> Draft, draft-ietf-lisp-sec-29, 7 July 2022, >> <https://www.ietf.org/archive/id/draft-ietf-lisp-sec- >> 29.txt>. >> >> [I-D.jeong-its-v2i-problem-statement] >> Jeong, J. P. and T. (. Oh, "Problem Statement for Vehicle- >> to-Infrastructure Networking", Work in Progress, Internet- >> Draft, draft-jeong-its-v2i-problem-statement-02, 19 July >> 2016, <https://www.ietf.org/archive/id/draft-jeong-its- >> v2i-problem-statement-02.txt>. >> >> [I-D.shen-isis-geo-coordinates] >> Shen, N. and E. Chen, "Carrying Geo Coordinates >> Information In IS-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 >> >>
Re: [lisp] Soliciting comments for draft-farinacci-lisp-satellite-01
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 discussion about this >> document and solicit review for comments. >> >> Does the WG think this should be a working group document? > > Before going to this step (WG adoption). > > Would be good if people read and review this document. > > Ciao > > L. > > > >> >> Please send comments. Thanks. >> >> Dino >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP PubSub to Proposed Standard?
> 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
Re: [lisp] Lisp Portable Edge Multipoint Sockets
> 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 draft. > Instead we want EID to mean address of communication objects: mp2p queues and > p2mp channels, which can move between hosts. Right, exactly. > This portability supports functional distributed programming models and > simplified on-path compute aware networking. Right an RLOC is an address pointer in a computer language and when you "deference it", you get the contents. But in a true virtual memory system the EID is an address pointer, and the OS finds where the contents are. > On-path awareness becomes important in the absence of centralized clouds > which hide DNS changes from clients, and contain the unpredictable latency of > co-located HTTP redirects. Right. > These geo-distributed compute conditions are relevant for the new AR/VR edge > applications, and this specification simplifies the description of > elastically scaling them using LISP. Agree. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Call for adoption for LISP Geo-Coordinate Use-Cases
> 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. Thanks. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] Soliciting comments for draft-farinacci-lisp-satellite-01
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 https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP WG Minutes Meeting IETF 115
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 wrote: > > Hi All, > > The minutes of our last meeting are online: > https://datatracker.ietf.org/meeting/115/materials/minutes-115-lisp-202211081630-00 > > Please have a look and send an email to the chairs for any comment. > > Ciao > > L. > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] Fwd: Lisp Portable Edge Multipoint Sockets
Yes, everything you can define the better. Even a "socket" since its an overloaded term. Plus you want to define terms based on how the document is going to use them. So defining "EID" in the context of your document would make the ideas more clear. Like an EID in this spec defines an object versus a host. I don't think there is a standard format for describing the API. Just calls and input and output parameter descriptions you should include. As for eBPF, just describe what filters you are need to use to associate packet flows with an EID. And that this is a local matter and the flows are NOT put in the mapping system like it could be for the Multi-Tuple draft. I am not sure who you are referring to but I know a lot of people that use eBPF. You should google for a list name and propose they review the document and definitely invite them to IETF. Dino > 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 true! > > Could you say this also on the list so we know theres workgroup interest in > developing this? > > What about the EID Queue/Channel API ? > Do we have any good existing format we can adapt/adopt ? > > How detailed should be the eBPF implementation description, can we engage the > eBPF people that came to the last IETF? I think you know one of them .. they > want to RFC eBPF itself. > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > >> On Nov 20, 2022, at 22:51, Dino Farinacci wrote: >> >> I think you need a lot more terms defined in your Definition of Terms >> section. Any reference to a new concept must be defined, even "edge compute >> IOT". >> >> And you need more on the "how" its done. You have plenty on what it is. >> >> Dino >> >>> On Nov 20, 2022, at 7:35 AM, Sharon Barkai >>> wrote: >>> >>> >>> Could you have a look? >>> Can make writing other edge application specs simpler.. >>> >>> >>> >> ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] Fwd: I-D Action: draft-farinacci-lisp-geo-15.txt
Folks, please have a look at the new text I wrote to reflect Alvaro an Jordi's comments. It has a new Privacy Considerations section. Please feel free to rephrase any text or word smith. Thanks, Dino > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: I-D Action: draft-farinacci-lisp-geo-15.txt > Date: November 10, 2022 at 4:33:49 PM GMT > To: > Cc: lisp@ietf.org > Reply-To: internet-dra...@ietf.org, lisp@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a 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 > > Abstract: > This draft describes how Geo-Coordinates can be used in the LISP > Architecture and Protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-geo-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-geo-15 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Call for adoption for LISP Geo-Coordinate Use-Cases
> 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 a copy and paste error from RFC6830. > • Wrt to privacy, maybe the document should require using some kind of > encryption between xTRs and the MS? > Thanks, Yes, I had planned to add that in the new Privacy Considerations section that Alvaro suggested. A new update coming soon. Thanks Jordi, Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] AD Review of draft-ietf-lisp-pubsub-09
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 cover on the NAT traversal spec. ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] AD Review of draft-ietf-lisp-pubsub-09
> On Nov 6, 2022, at 8:49 PM, Alberto Rodriguez-Natal (natal) > wrote: > > > Hi Dino, > > I’m referring to this exchange [1] between Alvaro and you, regarding the use > of ITR-RLOCs from the Map-Request as the addresses to use to send the > Map-Notifies to. > > The summary is that since Map-Requests include the “ITR-RLOC” fields, we are > using those, instead of the source address of the Map-Request, to send the > Map-Notifies. This is for both Map-Notifies used to ack subscription as well > as for Map-Notifies sent as publication (the Map-Server keeps track of the > last ITR-RLOCs received for a subscriber). > > Hope it makes sense :) It makes sense now but we have to be careful those ITR-RLOC addresses are translated public addresses so the Map-Notify can get back to ITRs through NATs. Dino > > Alberto > > [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...@ietf.org , > Vina Ermagan , Stefano Secci , > Fabio Maino (fmaino) , Sharon Barkai > , Albert Cabellos , Johnson > Leong , JACQUENET Christian INNOV/NET > , mohamed.boucad...@orange.com > > Subject: Re: AD Review of draft-ietf-lisp-pubsub-09 > > > [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 > > Map-Request-triggered Map-Notifies are sent to. > > This isn't making sense to me. Are you talking about a Map-Notify as an ack > to the Map-Register or an unsolicited Map-Notify and if the latter, the > notification is going to the source address of the LAST subscription request. > And if another Map-Request came later with the N-bit set again, with a > new/different source IP address, the map-server must cache the last address > (and later send Map-Notify to this new address). > > Agree? > > Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] AD Review of draft-ietf-lisp-pubsub-09
> [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 > Map-Request-triggered Map-Notifies are sent to. This isn't making sense to me. Are you talking about a Map-Notify as an ack to the Map-Register or an unsolicited Map-Notify and if the latter, the notification is going to the source address of the LAST subscription request. And if another Map-Request came later with the N-bit set again, with a new/different source IP address, the map-server must cache the last address (and later send Map-Notify to this new address). Agree? Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP PubSub to Proposed Standard?
> On Nov 6, 2022, at 12:27 PM, Alberto Rodriguez-Natal (natal) > wrote: > > On the meantime, what is the view of the WG on moving the document to > Proposed Standard? I think it is critical to carry this fundamental solution as Proposed Standard. We have struggled for years keeping mappings up to date on proxy-ITRs. Pubsub provides an event triggered solution which I believe is fundamental functionality the architecture needs. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Call for adoption for LISP Geo-Coordinate Use-Cases
Me too. :-) Dino > On Oct 29, 2022, at 9:33 AM, Sharon Barkai > wrote: > > Support of course. > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > >>> On Oct 29, 2022, at 14:43, Luigi Iannone wrote: >>> >> Folks, >> >> The author of the document LISP Geo-Coordinate Use-Cases did ask the chairs >> to open a call for adoption. >> >> You can find the document at: >> https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/ >> >> This email formally opens the two weeks Call for adoption. >> If you are supporting adoption, please state so. >> If you have concerns, please detail them. >> >> The call will close on November 12th 2022. >> >> The chairs Luigi and Padma >> >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP Specifications Published!! :-)
Alvaro wanted to get to the pubsub draft as next to go to standards track. And I suggested that the multicast drafts (6831 and 8378) are stable and should be standards track fi noish the complete set. Dino > On Oct 27, 2022, at 8:32 PM, Xiejingrong (Jingrong) > wrote: > > Hi Dino, > > Yes, it's a typo and should be RFC 8378. > Sorry, I haven't seen anything in the list about multicast topic today or > back in this month or this year. Can you please provide the link or just tell > the plan. > I have quickly looked at 9299 (informational) and 9300 (Standard) and found > both have contents about multicast and have normative references to 6831 & > 8378. > > Thanks, > Jingrong > > -Original Message- > From: Dino Farinacci [mailto:farina...@gmail.com] > Sent: Friday, October 28, 2022 11:11 AM > To: Xiejingrong (Jingrong) > Cc: Padma Pillay-Esnault ; Albert Cabellos > ; lisp@ietf.org list > Subject: Re: [lisp] LISP Specifications Published!! :-) > > I just brought that up in the list today. And it’s RFC 8378. I think you may > have a typo below. > > Dino > >> On Oct 27, 2022, at 8:07 PM, Xiejingrong (Jingrong) >> wrote: >> >> Congratulations to everyone ! >> I may be late joining LISP, and apologize in advance if my following >> question is repeated: >> Will the LISP multicast RFCs 6831 & 8379 have bis to advance them from >> Experimental to Standard ? >> >> Thanks, >> Jingrong >> >> 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ >> This e-mail and its attachments may contain confidential information from >> HUAWEI, which is intended only for the person or entity whose address is >> listed above. Any use of the information contained herein in any way >> (including, but not limited to, total or partial disclosure, reproduction, >> or dissemination) by persons other than the intended recipient(s) is >> prohibited. If you receive this e-mail in error, please notify the sender by >> phone or email immediately and delete it! >> >> -Original Message- >> From: lisp [mailto:lisp-boun...@ietf.org] On Behalf Of Padma Pillay-Esnault >> Sent: Sunday, October 23, 2022 11:35 PM >> To: Dino Farinacci >> Cc: Albert Cabellos ; lisp@ietf.org list >> >> Subject: Re: [lisp] LISP Specifications Published!! :-) >> >> Congratulations to Everyone! >> It was indeed a long process and thanks to everyone involved. >> >> Cheers >> Padma >> >>>> On Oct 23, 2022, at 07:45, Dino Farinacci wrote: >>> >>> A special thanks to you Albert. You were the backbone of this long >>> standing publication process. >>> >>> Dino >>> >>>>> On Oct 23, 2022, at 2:49 AM, Albert Cabellos >>>>> wrote: >>>> >>>> Congrats to everyone involved! And also thanks for the final push that >>>> made this possible >>>> >>>> Albert >>>> >>>>>> On 22 Oct 2022, at 10:56, Luigi Iannone wrote: >>>>> >>>>> A nice team work :-) >>>>> >>>>> Congrats all. >>>>> >>>>> L. >>>>> >>>>>>> On 21 Oct 2022, at 06:59, Dino Farinacci wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Now it’s time to pull the Prosecco! >>>>>> >>>>>> Make it a DOC! >>>>>> >>>>>> Dino >>>>>> >>>>>> ___ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>>> ___ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>> >>> ___ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP Specifications Published!! :-)
I just brought that up in the list today. And it’s RFC 8378. I think you may have a typo below. Dino > On Oct 27, 2022, at 8:07 PM, Xiejingrong (Jingrong) > wrote: > > Congratulations to everyone ! > I may be late joining LISP, and apologize in advance if my following question > is repeated: > Will the LISP multicast RFCs 6831 & 8379 have bis to advance them from > Experimental to Standard ? > > Thanks, > Jingrong > > 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments may contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient(s) is prohibited. > If you receive this e-mail in error, please notify the sender by phone or > email immediately and delete it! > > -Original Message- > From: lisp [mailto:lisp-boun...@ietf.org] On Behalf Of Padma Pillay-Esnault > Sent: Sunday, October 23, 2022 11:35 PM > To: Dino Farinacci > Cc: Albert Cabellos ; lisp@ietf.org list > > Subject: Re: [lisp] LISP Specifications Published!! :-) > > Congratulations to Everyone! > It was indeed a long process and thanks to everyone involved. > > Cheers > Padma > >> On Oct 23, 2022, at 07:45, Dino Farinacci wrote: >> >> A special thanks to you Albert. You were the backbone of this long standing >> publication process. >> >> Dino >> >>>> On Oct 23, 2022, at 2:49 AM, Albert Cabellos >>>> wrote: >>> >>> Congrats to everyone involved! And also thanks for the final push that >>> made this possible >>> >>> Albert >>> >>>>> On 22 Oct 2022, at 10:56, Luigi Iannone wrote: >>>> >>>> A nice team work :-) >>>> >>>> Congrats all. >>>> >>>> L. >>>> >>>>>> On 21 Oct 2022, at 06:59, Dino Farinacci wrote: >>>>> >>>>> >>>>>> >>>>>> Now it’s time to pull the Prosecco! >>>>> >>>>> Make it a DOC! >>>>> >>>>> Dino >>>>> >>>>> ___ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> ___ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] RtgDir Early review: draft-ietf-lisp-name-encoding-00
Thanks Chris. The encoding is length based via the LCAF format. And now we are sync'ed with IS-IS and OSPF encodings. Dino > On Oct 25, 2022, at 11:38 AM, Christian Hopps wrote: > > Hello, > > I have been selected to do a routing directorate "early" review of > this draft. > > https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/ > > The routing directorate will, on request from the working group > chair, perform an "early" review of a draft before it is submitted > for publication to the IESG. The early review can be performed at > any time during the draft’s lifetime as a working group document. > The purpose of the early review depends on the stage that the > document has reached. > > As this document is in working group last call, my focus for the > review was to determine whether the document is ready to be > published. Please consider my comments along with the other > working group last call comments. > > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Document: draft-ietf-lisp-name-encoding-00 > Reviewer: Christian Hopps > Review Date: October 25, 2022 > Intended Status: Experimental > > Summary: > > No issues found. This documents is ready to proceed to the IESG. > > Comments: > > The document is well written and easy to understand. Personally, I > would have gone with a length value for performance and implementation > simplicity; however, seeing as this document has already been around > and reviewed for a while (and I believe from reading the mailing list, > it's already deployed), and more importantly the WG (the experts in > LISP) have had this point brought up and are happy with the existing > solution, I see no reason to push back against it. > > Thanks, > Chris. ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] LISP Specifications Published!! :-)
A special thanks to you Albert. You were the backbone of this long standing publication process. Dino > On Oct 23, 2022, at 2:49 AM, Albert Cabellos wrote: > > Congrats to everyone involved! And also thanks for the final push that made > this possible > > Albert > >> On 22 Oct 2022, at 10:56, Luigi Iannone wrote: >> >> A nice team work :-) >> >> Congrats all. >> >> L. >> >>>> On 21 Oct 2022, at 06:59, Dino Farinacci wrote: >>> >>> >>>> >>>> Now it’s time to pull the Prosecco! >>> >>> Make it a DOC! >>> >>> Dino >>> >>> ___ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
