Re: [lisp] LISP standardization request from ICAO WG-I

Thank you for your interest in the LISP work. First, I recommend that anyone interested in IETF work read https://www.ietf.org/tao.html as that will give you a better understanding of the IETF process. The IETF is in the process of moving the base LISP specifications from experimental to

Re: [lisp] Comments on draft-kouvelas-lisp-map-server-reliable-transport-07 presentation at LISP WG

As I understand it, we need both a UDP port number and a destination connection ID. Yours, Joel On 3/22/2022 10:44 AM, Dino Farinacci wrote: Heard back from a QUIC expert. Thanks for the quick response. As long as we do not want to use QUIC over HTTP, we can use whatever UDP port we want

Re: [lisp] Comments on draft-kouvelas-lisp-map-server-reliable-transport-07 presentation at LISP WG

Heard back from a QUIC expert. As long as we do not want to use QUIC over HTTP, we can use whatever UDP port we want to carry QUIC. I would note that since we may want to have the same node provide connectionless (UDP-based) LISP and connection orient (TCP or QUIC) LISP, it seems that if we

Re: [lisp] Comments on draft-kouvelas-lisp-map-server-reliable-transport-07 presentation at LISP WG

As far as I can tell, QUIC is always UDP destination port 443. Waiting to hear from my email. Yours, Joel On 3/22/2022 9:23 AM, Dino Farinacci wrote: I am checking with a QUIC expert. From some preliminary checking, it looks like QUIC runs over a well known UDP destination port. So we

Re: [lisp] Comments on draft-kouvelas-lisp-map-server-reliable-transport-07 presentation at LISP WG

I am checking with a QUIC expert. From some preliminary checking, it looks like QUIC runs over a well known UDP destination port. So we can't run QUIC over a separate UDP destination port for LISP. I have asked what we should do to specify that the QUIC connection is for LISP. Yours, Joel

[lisp] Fwd: FW: NomCom 2021-2022 Call for Community Feedback

It was noted that the nomcom is still very much asking for feedback, so per suggestions from other WG chairs, I am re-posting this call for feedback. Please give the nomcom your input, Joel On 10/19/21, 10:28 AM, "NomCom Chair 2021" wrote: Hi IETF, The deadline for nominee

[lisp] Fwd: Second Call for Nominations

Please, help the nomcom. Yours, Joel Forwarded Message Subject: Second Call for Nominations Date: Tue, 05 Oct 2021 10:50:50 -0700 From: NomCom Chair 2021 Reply-To: i...@ietf.org To: IETF Announcement List CC: i...@ietf.org Hello IETF Community! Only one week to go and we

[lisp] Fwd: NomCom 2021-2022 Call for Nominations

Please do volunteer and nominate others. Also, when they get to calling for feedback, please do comment. Yours, Joel Forwarded Message Subject: NomCom 2021-2022 Call for Nominations Date: Mon, 30 Aug 2021 07:03:54 -0700 From: NomCom Chair 2021 Reply-To: i...@ietf.org To:

Re: [lisp] Upcoming meeting

r WGs that may look at LISP to help solve some of their problems. And even if the topics are tutorial in nature, that will foster discussion IMO. Dino On Aug 12, 2021, at 2:49 PM, Joel M. Halpern wrote: Your chairs have until September 24th to request a slot at the next meeting. Participants indi

[lisp] Upcoming meeting

Your chairs have until September 24th to request a slot at the next meeting. Participants indicated a desire for a 2 hour slot. Before requesting that, I at least (I have not asked Luigi) want evidence tha there will be actual discussion. Burning two hours for presentations that do not lead

[lisp] Regarding identifiers in draft-kowal-lisp-policy-distribution

In the discussion at the session, it was suggested that the distinguished names are distinguished because of instance IDs. If that is the intention, the draft needs to clearly state that this is to be done using its own instance ID, that no other use of distinguished names shall be made

[lisp] Fwd: Second (of three) NomCom 2021-2022 Call for Volunteers

Please consider volunteering for the IETF nomcom. The community needs your participation. Thank you, Joel Forwarded Message Subject: Second (of three) NomCom 2021-2022 Call for Volunteers Date: Tue, 08 Jun 2021 20:41:10 -0700 From: NomCom Chair 2021 Reply-To: i...@ietf.org

Re: [lisp] Quick Mobility Update

The currently gating items on the bis work is RFC 6834bis. We are working to get that done. We will work on nexagon when the base documents are done. Yours, Joel On 5/23/2021 2:59 AM, Sharon Barkai wrote: The LISP-Nexagon interface is being used in this AECC TR (Toyota, Oracle) to express

[lisp] Fwd: NomCom needs your feedback!

This request came from the nomcom chair. The nomcom needs your input. Please. Thank you, Joel Forwarded Message Subject: NomCom needs your feedback! Date: Tue, 10 Nov 2020 16:10:17 -0800 From: NomCom Chair 2020 To: IETF Announcement List CC: i...@ietf.org Hi IETF, NomCom

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

One can do many things on an ad-hoc basis. But if we are telling people how to implement mapping systems, we have to tell them what they need to do. And if people are using mapping systems, they have to know what they can expect from the mapping system. Yours, Joel On 10/2/2020 12:04 PM,

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

On what basis would the mapping system decide if a full match or prefix match is appropriate? So far, each EID has been specific on what kind of lookup it does. IP (v4 or v6) lookups always do LPM lookups. All other EIDs we have specified so far do exact matches. Yours, Joel On 10/2/2020

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

Another way of looking at my issue here is the many problems the DNS folks have had with tXT records. They are free-form text. Making them useful has proven to be a major challenge. hence, even as RLOCs rather than EIDs (where the collision problem is not an issue), I am concerned that

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

In line, preserving all for now, but we will need to trim or top-post soon. Yours, Joel On 9/29/2020 3:42 PM, Dino Farinacci wrote: Looking again at this draft, and at the example Dino points to, I think there is a basic problem with the work and the usage. the problem is not a problem for

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

Looking again at this draft, and at the example Dino points to, I think there is a basic problem with the work and the usage. the problem is not a problem for the mapping system per se. It is a problem for usage. The draft does not define any mechanism for structuring, allocating, or

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

As chair, I would really like to see something more than just +1. For example, what do you see this as being useful for? Yours, Joel On 9/28/2020 1:29 AM, Albert López wrote: +1 Albert L. On 27/9/20 9:36, Dino Farinacci wrote: I did not see any objections for this request but I didn’t see

Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

inning of large packets to verify that they match the echoed packet in ICMP Frag Needed/PTB." Feel free to re-word, of course. This can either be in the section or mentioned in security considerations with a pointer in 7.2. Martin On Thu,

[lisp] Fwd: Protocol Action: 'LISP Generic Protocol Extension' to Proposed Standard (draft-ietf-lisp-gpe-19.txt)

One down... Yours, Joel Forwarded Message Subject: Protocol Action: 'LISP Generic Protocol Extension' to Proposed Standard (draft-ietf-lisp-gpe-19.txt) Date: Tue, 11 Aug 2020 14:39:29 -0700 From: The IESG To: IETF-Announce CC: lisp-cha...@ietf.org, lisp@ietf.org,

Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

only" recommendation is just wrong and should be reverted. On Thu, Aug 6, 2020 at 1:48 PM Joel M. Halpern <mailto:j...@joelhalpern.com>> wrote: Martin, I want to check one aspect of your response about MTU handling. The entity which is originating the packets, and

Re: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

Martin, I want to check one aspect of your response about MTU handling. The entity which is originating the packets, and receiving the ICMP responses, is the ITR. In most cases, the ITR is a router. I do not know of any tunnel protocol for rotuers that expects the routers to store state

Re: [lisp] Fwd: New Version Notification for draft-farinacci-lisp-simple-nat-00.txt

Dino, trying to make sure I am reading this right. How does the Map Server decide which set of answers to give? It magically knows which requesters are RTRs? It compares the requester with the registered entries? And am I reading it right that this draft assigns special meaning

Re: [lisp] LISP WG Interim Date

We do not get to give the IESG deadlines, no matter how much we want to. And with the change in Transport ADs, it is (unfortunately) reasonable to give him some time to get up to speed. Luigi and I should send a note to Deborah asking her to talk with the new Transport AD. Yours, Joel PS:

Re: [lisp] Virtual meeting

-external-connectivity-00). If slots are still available in virtual session, we would like to have 10 min slot to discuss this. Thanks, Prakash On 3/10/20, 2:44 PM, "lisp on behalf of Joel M. Halpern" wrote: Vancouver has been cancelled. We have several ways we can hold a virtu

Re: [lisp] Virtual meeting

should try to make it lighter weight. And you can’t do what you want on the MR, because its the MS’s OTK as spec’ed today that is passed to the ETR. Dino On Mar 31, 2020, at 4:58 PM, Joel M. Halpern wrote: We could reuse the OTK directly. My actual inclination would be for the MR to send

Re: [lisp] Virtual meeting

We could reuse the OTK directly. My actual inclination would be for the MR to send back (via the ETR) some data which, when combined with the OTK, produced a separate key for use with the notify messages. Clearly, the MR would have to store whatever security key we want it to use as long as

Re: [lisp] Virtual meeting

I may have missed something, but I think that in the case of the first notify, it does actually start at the Itr. Specifically, it starts with an ItR sending a subscribe request. The MS responds to that with a notify. What I am suggesting is that (when security is desired) the Itr includes

Re: [lisp] Virtual meeting

thinking about Alberto's request, and reading the document, I wondered if the security could be improved by sending the first notify back via the ETR, and coupling it to LISP-SEC to protect the information and provide needed keys for further messages? It seems like we do need a way to protect

Re: [lisp] I-D Action: draft-ietf-lisp-pubsub-05.txt

Thanks. That will work fine. Yours, Joel On 3/20/2020 5:50 AM, mohamed.boucad...@orange.com wrote: Hi Joel, Good catch. I think we just need to delete that second sentence. The behavior when pubsub is not supported is covered by this text: Upon receipt of the Map-Request, the

Re: [lisp] Virtual meeting

No, fundamentally, WG sessions are not supposed to be opportunities to present. They are supposed to be opportunities to use higher bandwidth to resolve issues. Even virtual meetings are supposed to be for that goal. Of the several presentations at the last meeting, most had no comments,

Re: [lisp] Virtual meeting

Many of the things that I believe folks would like to discuss are in charter. Dino, I think you misunderstood my point. I am looking to see discussion on the list to give me confidence that a virtual session will be useful. I have been disappointed in the one-way nature of the last several

[lisp] Virtual meeting

Vancouver has been cancelled. We have several ways we can hold a virtual interim. (The chairs have a webex available, and Fabio has offered one.) I understand that folks want to present their work. But what I am looking for if we are going to get folks together is actual engagement on the

Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48

is and why. What if there is *any* usage for any subblock? Dino Yours, Joel On 8/1/2019 2:33 PM, Dino Farinacci wrote: No, its not about me. RIPE wants to stop allocating experimental EID blocks. Do we, the LISP WG, want that to happen? Dino On Aug 1, 2019, at 10:46 AM, Joel M. Halpern wr

Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48

. RIPE wants to stop allocating experimental EID blocks. Do we, the LISP WG, want that to happen? Dino On Aug 1, 2019, at 10:46 AM, Joel M. Halpern wrote: I am presuming your phrasing is slightly misleading. If you individually are the only user of the block, I do not see how we can justify

Re: [lisp] Fwd: #202719 - Re: LISP EID prefix 2001:5:3::/48

I am presuming your phrasing is slightly misleading. If you individually are the only user of the block, I do not see how we can justify asking RIPE to continue the assignment. Yours, Joel On 8/1/2019 1:00 PM, Dino Farinacci wrote: I am still using this block but RIPE wants to remove it per

Re: [lisp] Intended status on some of our LISP WG documents

Let's get the current set moved to PS. Then we can see if any of the other experiments are sufficiently mature to move them. (Some probably are.) Yours, Joel On 7/8/19 5:56 PM, Victor Moreno wrote: Hi Joel, Luigi, Most of the WG documents are flagged for Experimental RFC status. I can

Re: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-rfc8113bis-02: (with COMMENT)

To amplify Dino's response, it is not anticipated that any of the changes that might still be needed to rfc6833bis would affect rfc8113bis in any way. Of course the unanticipated can happen, and we will make sure the IESG is informed if it does. Yours, Joel On 1/22/19 10:33 PM, Dino

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

signed via Standards Action [RFC8113]. Cheers, Med -Message d'origine- De : Dino Farinacci [mailto:farina...@gmail.com] Envoyé : mercredi 19 décembre 2018 19:00 À : BOUCADAIR Mohamed TGI/OLN Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-rfc8

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

” I always had a problem with because it can be interpreted as “replacing". Replacing something to fix a problem. 8113 is simply asking for one of the type value codepoint, so there can be another format to have more types. Dino On Dec 18, 2018, at 9:24 PM, Joel M. Halpern wrote: Au

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

Authors: that sounds like a reasonable addition to me? Yours, Joel On 12/18/18 10:48 PM, Brian E Carpenter wrote: On 2018-12-19 15:46, Joel M. Halpern wrote: This is part of the package to move the coherent set of base LISP specs to PS. The reason we did this rather than folding

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

This is part of the package to move the coherent set of base LISP specs to PS. The reason we did this rather than folding it into 6830bis / 6833bis is that we had originally simply cited 8113, and then realized that needed to move to PS along with everything else. It seemed (and is) simpler

Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned

Actually, given the existence of RFC 8126, varying from that recommendation for the distinction between Reserved and Unassigned (by which, what we mean is Unassigned) should only be done with very good reason. Yours, Joel On 10/25/18 11:04 AM, Dino Farinacci wrote: It doesn’t *have to be*

Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned

future use. It MUST be set to 0 on transmit and MUST be ignored on receipt. Cheers, Med -Message d'origine- De : Joel M. Halpern [mailto:j...@joelhalpern.com] Envoyé : mercredi 24 octobre 2018 15:15 À : BOUCADAIR Mohamed TGI/OLN; Luigi Iannone; Dino Farinacci Cc : lisp@ietf.o

Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned

Med, just to be clear. Ar eyou saying that we should change the word Reserved to Unasigned? THe text would read weirdly, but I can live with it. We need to keep the rest of the text, as it is critical for future interoperability. Yours, Joel On 10/24/18 5:24 AM,

Re: [lisp] "Update RFC6833bis" header when a meaning is associated with a reserved bit

For everyone's context, this is a topic on which the IETF as a whole and the IESG do not have anything like rough consensus. Some folks think this sort of change should be an "updates", and other folks argue that the point of a registry is that we do not need to "update" the base document.

[lisp] Drafts; and expiration

Reminder that the draft cutoff is Monday. Particularly for expiring drafts which are still in the WG but needed for the advancments process (.e.g LISP-SEC) please refresh before the deadline. Thank you, Joel ___ lisp mailing list lisp@ietf.org

Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

This draft explicitly states that the m-bit can be ignored by nodes that do not support the lisp mobile node behavior. Which seems pretty clear that it is nicely separable. Yours, Joel On 9/29/18 1:30 PM, Eric Rescorla wrote: On Sat, Sep 29, 2018 at 10:24 AM Joel M. Halpern <mailt

Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

wrote: On Sat, Sep 29, 2018 at 10:18 AM Joel M. Halpern <mailto:j...@joelhalpern.com>> wrote: With regard to the m-bit, I would prefer that this document leave the bit reserved, Just trying to think through the interop implications of this. Would it be must be zero and mu

Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

With regard to the m-bit, I would prefer that this document leave the bit reserved, and the LISP mobile node document assign the bit fromthe registry. That keeps a clean separation. Yours, Joel On 9/29/18 1:05 PM, Eric Rescorla wrote: On Sat, Sep 29, 2018 at 9:30 AM Dino Farinacci

Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

Thank you Benjamin. This response helps me understand the situation. I have sent a note to the WG about making LISP-SEC MTI. That kind of change needs WG support. Yours, Joel On 9/28/18 6:03 PM, Benjamin Kaduk wrote: Hi Joel, On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern

Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

Is there text we can add about the scoping that will change your discuss into a series of useful comments? If so, Some indication of how you would like that phrased would help us address these. If not, we seem to have a larger problem. Yours, Joel On 9/26/18 11:44 PM, Benjamin Kaduk wrote:

Re: [lisp] Fwd: Alvaro Retana's No Objection on draft-ietf-lisp-rfc6830bis-16: (with COMMENT)

Any change to lisp-intro should be done by discussion with the RFC Editor, as it is in the RFC Editor queue (pending reference completion). If the working group considers it acceptable, we could easily ask them to change the references to 6830 and 6833 to the bis documents (after all, it is

[lisp] Presentations

Presenters, please get your material to the chairs and WG secretary (sending to lisp-cha...@ietf.org will work fine). While we are scheduled later in the week, the earlier you get us the material, the better. Thank you, Joel ___ lisp mailing list

Re: [lisp] Fwd: I-D Action: draft-iannone-6834bis-00.txt

Yeah, if we wanted to take longer we could put in a filename change. But it doesn't actually matter. (usually, we need the name right so folks can find the document. I don't think that is a problem in this case.) I will do what is needed to attach it to the LISP WG page. Yours, Joel On

[lisp] RFC 6834bis

Luigi notied that there is one more document that our PS set depends on. RFC 6834: Locator/ID Separation Protocol (LISP) Map-Versioning Since we will need to move this to PS, the rules prohibit us from simply doing a downref. As such, unless our AD tells us we can't expedite this, the plan

Re: [lisp] The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state "Call For Adoption By WG Issued"

ft-ietf-lisp-pubsub-00. Thanks Luigi & Joel > On 4 Apr 2018, at 03:26, Joel M. Halpern <j...@joelhalpern.com <mailto:j...@joelhalpern.com>> wrote: > > This was discussed in London, and the authors have requested working group adoption.

Re: [lisp] The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state "Call For Adoption By WG Issued"

This was discussed in London, and the authors have requested working group adoption. Please comment on whether you think this document is ready for WG adoption. Which does not mean it is perfect, but rather that it is a good start on the problem it aims to solve. Comments with motivation or

Re: [lisp] Review 6833bis

The last diff I can find in my email from you (which may not be the last diff) still has the text that "Documents that request for a new LISP packet type MAY indicate a prefrred value in section 10.4." What Luigi had suggested was: Documents that request for a new LISP packet type MAY

Re: [lisp] Review 6833bis

, 2018, at 6:47 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: Assuming this 10.4 is now 7.3 and that we are disucssing the text in 4.1, as written the text does not make sense A new document can not specify a preferred value in a section in an existing document. I am not sure what it is

Re: [lisp] Review 6833bis

Assuming this 10.4 is now 7.3 and that we are disucssing the text in 4.1, as written the text does not make sense A new document can not specify a preferred value in a section in an existing document. I am not sure what it is trying to say. It mostly seems to be saying something that is IANA

Re: [lisp] [Ila] LISP for ILA - scaling

From the analysis Eliot did many years ago for a LISP push solution, for any constrained solution (a data center, a mobile operator, a fixed service operator) the number of entries is probably not a problem. Even for a conventional router. Churn rate, in its various manifestations, could

Re: [lisp] RFC 8112

It is not listed because it is not a working group product. It is an Independent Stream document from the authors. (I agree it is a useful document, but that is not whta that list is about.) Yours, Joel On 2/23/18 12:34 PM, Dino Farinacci wrote: Chairs, can you check why RFC 8112 is not

Re: [lisp] Confirm/Deny changes on draft 6830bis

Assuming Luigi agrees, there should be a version of this dcoument submitted that incorporates what Dino did for A and C, and addresses D - G. Yours, Joel On 1/28/18 10:07 PM, Dino Farinacci wrote: Note A and C are addressed in the -09 revision I sent out in Friday. Dino On Jan 28, 2018, at

Re: [lisp] 6830bis Review

If there is silence, the chairs will make their best judgment on behalf of the working group. That is our job. The other choice is that we block the document until there are enough voices. I would prefer not to do that. Yours, Joel On 1/15/18 1:16 PM, Dino Farinacci wrote: (Yes, my

Re: [lisp] 6830bis Review

Let's try to separate things. 1) The fact that the messages are used only between xTRs does not tell us whether it is control or data. 2) The manipulation of map-cache may well be control (for example, if we were using a push-based control mechanism then map-cache control would be largely

Re: [lisp] 6830bis Review

Working group: I see folks making a case for SMR being in either 6830bis or 6833bis. It is up to the WG. What say you? Yours, Joel On 1/11/18 12:50 PM, Dino Farinacci wrote: Thanks Alberto for your comments. Here is how I break up items in the control-plane and the data-plane. Control-Plane

Re: [lisp] 6830bis Review

I would talk about that purely in terms of RLOCs being dervice from, and assigned according to, the underlay. It is up to the underlay to set it policies so that it scales well (or chooses not to care, as some underlays do.) Yours, Joel On 12/27/17 11:44 PM, Dino Farinacci wrote: Actually,

Re: [lisp] 6830bis Review - control relationship

Trimmed... I agree with Dino here. There has never been a requirement that the LISP data plane work with anything other than the LISP control plane. Strictly speaking, it is not even a requirement that the LISP control plane be capable of supporting anything other than the LISP data plane.

Re: [lisp] 6830bis Review

Actually, I do not see why the LISP spec should talk at all about the scalability of the underlay. The underlay is what it is. We are not claiming to change that. Working Group: Does anyone else have an opinion either way? This document belongs to the WG, not to the chairs or the editors.

Re: [lisp] 6830bis Review - scalability

Clearly, scalability of LISP matters. However, we are explicitly not attempting to move LISP to standards track for purposes of solving global Internet address scaling problems. The agreement under which we are doing this is to focus on the value of the other uses of LISP. To put it simply

Re: [lisp] RFC6830bis and multiprotocol support

12/14/17 10:11 AM, Joel M. Halpern wrote: Let's separate things: 1) We can have a call for adoption of LISP GPE.  Meetings are not special in terms of working group formal actions. agree. Doing it seems to be helpful whatever the WG decides to do with 6830bis. That works for me. 2) My persona

Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption

the register if the MS cannot keep up. Depending on your implementation the xTR can stop building registration message until flow control is off with the MS. -Johnson On Dec 6, 2017, at 12:17 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: Johnson, I think your example may cause more problems

Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption

Johnson, I think your example may cause more problems. I am not sure what you mean by "over-subscribed". But if the xTR sends a registration over TCP, and gets no answer, it is going to asume that it is properly registerd. If the registration has not been received due to the receiver not

Re: [lisp] IDEAS @IETF98 Minutes

Regarding the second of your two points, I am not following you: On 10/11/17 8:00 PM, Sharon wrote: Discussed these 2 ID networking items with Albert and others, perhaps this is a good thread: ... 2. Lisp-Lambda - A serverless (or virtual-appliance-less) alternative to service function

Re: [lisp] xTR-ID for Map-Request in RFC6833bis

I can well believe that is useful. It would help you you provided use case? Yours, Joel On 9/19/17 10:34 PM, Alberto Rodriguez-Natal wrote: Hi all, We would like to suggest updating rfc6833bis [1] to include the xTR-ID in the Map-Request, in the same way that is already defined for the

Re: [lisp] Shared from BBC News

Sorry, typo. Joel On 9/18/17 2:17 PM, Joel M. Halpern wrote: http://www.bbc.com/news/world-us-canada-41310587 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp

[lisp] Shared from BBC News

http://www.bbc.com/news/world-us-canada-41310587 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6833bis - NMR with locator count !=0

convey the RLOC of the PETR plus the IID to which the Internet connects at the PETR. -v On Aug 21, 2017, at 11:12 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: Can you explain what information you are conveying with the RLOCs? I think we would need a clear use case before ch

Re: [lisp] 6833bis - NMR with locator count !=0

Can you explain what information you are conveying with the RLOCs? I think we would need a clear use case before changing the spec. Yours, Joel On 8/22/17 2:07 AM, Victor Moreno (vimoreno) wrote: Dear WG, As we put some of our specifications to the test in deployments, we have found the

Re: [lisp] Do we need a 8113bis?

(speaking personally) I would think that RFC 6830bis and RFC 6833bis can update the relevant registry entries. Whether that means they formally update RFC 8113 or not is a detail we can determine later. Registries can get changed, updated, etc. That is why we have registries. Yours, Joel

Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt

It is unusual for an RFC to refer to itself as authoritative. It is also not particularly helpful to use those words. In particular, values from the range 9 - 14 may be assigned by other standards action without updating 6833bis. (side-note, there is an long ongoing discussion on the IETF and

Re: [lisp] Map-Regiister Key-ID field

This looks workable. I think the wording needs adjustment. As written, it assumes a certain relationship in how the keys for the security association between the ETR and the Map Server are define (the Mapping System Provider decides to change the keys.) In practice, key change may be driven

Re: [lisp] Request for private LCAF allocation

That does not sound quite right. If the problem is experimentation, then what you describe (reserving one code point, if you need several structure your use in such a way to give you the spac eyou need) makes good sense. If the problem is private use LCAF types being deployed in production,

Re: [lisp] Please Review 6830bis and 6833bis

It looks to me like Policy_Denied and Authentication-Failure are error codes, not dispositions. They presumably go with the "Drop" action (as is the defined behavior for any ACT which is not understood. Given that the action is the same as Drop, it seems safe, but odd, to use different

Re: [lisp] Please Review 6830bis and 6833bis

Dino, I am missing something. If, as we both seem to be saying, the "policy-denied" response can go with any of the existing actions, how is the receiver to know which is intended by the responder? Yours, Joel On 3/12/17 9:19 PM, Dino Farinacci wrote: Right. It can be used to give

Re: [lisp] One comment to draft-ietf-lisp-type-iana-05.txt

On Feb 2, 2017, at 10:44 AM, Joel M. Halpern <j...@joelhalpern.com> wrote: I had not realized we intended to defer creation of the registry until we publish 6833bis. Yours, Joel On 2/2/17 1:26 PM, Dino Farinacci wrote: Mohamed, the statement “This document updates RFC6830.” is too

Re: [lisp] One comment to draft-ietf-lisp-type-iana-05.txt

I had not realized we intended to defer creation of the registry until we publish 6833bis. Yours, Joel On 2/2/17 1:26 PM, Dino Farinacci wrote: Mohamed, the statement “This document updates RFC6830.” is too broad and easily open to misinterpretation. See my suggestion below. I suggest this

Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)

With regard to status, I think we can work with you. But we really want to establish the registry now. We already have proposals for code points beyond the experimental RFCs, and requests for room to experiment without writing an RFC. As far as I can tell, the Working Group intent is that the

[lisp] Fwd: [rfc-i] The RFC Format docs are now RFCs

The RFCs described the intended evolution of the RFC Format are, as per the notice from Heather below, now available. Please take a look. The IESG has indicated that as the tooling development progress, they will allow these features in IDs. They also note that early testing is obviously

Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt

You raise an interesting point Geoff. The documents are experimental. As such, it is reasoanble for this document to be experimental, and for it merely to require IETF RFC for assignment, without restricting it to Standards Track RFCs. And while we are in the process of moving the LISP

Re: [lisp] [Ideas] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

. Thoughts? Padma On Fri, Oct 28, 2016 at 8:15 PM, Joel M. Halpern <j...@joelhalpern.com <mailto:j...@joelhalpern.com>> wrote: There are some preliminary thoughts on overload issues in the security considerations of draft-ietf-lisp-introduction. I will also be curious

Re: [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

There are some preliminary thoughts on overload issues in the security considerations of draft-ietf-lisp-introduction. I will also be curious to see what the presentations at the technical plenary in Seoul have to suggest on the issue, if anything. There probably is more with considering.

Re: [lisp] LISP-SEC review (finally)

The usual practice, although there are exceptions, is to indicate along with the SHOULD the kinds of circumstances that would justify not complying with that SHOULD while implementing (most of) the rest of the RFC. Yours, Joel On 10/21/16 7:23 PM, Fabio Maino wrote: Ciao Luigi, below I have

[lisp] Fwd: Re: CodeStand

FYI... Forwarded Message Subject: Re: CodeStand Date: Thu, 13 Oct 2016 12:59:43 + From: Christian O'Flaherty To: routing-discuss...@ietf.org CC: codestand-deve...@ietf.org Please note that a

Re: [lisp] Fwd: Expiration impending:

to, this can not be used to carry UTF-8 to the fact that bytes of all 0 may occur in UTF-8. There are many good reasons to keep this simple scope. If we want to keep that restrictions, it seems to me that the introduction should be clear about the scope. Yours, Joel M. Halpern On 10/3/16 12

Re: [lisp] RtgDir review: draft-ietf-lisp-lcaf-14.txt

Thanks Stig. This looks very useful. Authors, can you please respond? Yours, Joel On 9/7/16 4:41 PM, Stig Venaas wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass

Re: [lisp] Changing the title of draft-ietf-lisp-yang

Vina sent a note to the list on 25-July suggesting that the title of this draft be changed to: YANG Model for LISP There saw noticeable support, and no objections. As such, Vina, please go ahead and make that change when you next submit a revision of the draft. Yours, Joel and Luigi

  1   2   3   >