Re: [lisp] New name for upcoming LISP -OAM- document

> The suggested name is “LISP Mobility, Deployment and Traceroute > considerations”. > > The chairs would like to hear from the mailing list if there is any objection > or you have a better name to suggest. I don’t have a name suggestion (for the 3 items included in one document) but I would

Re: [lisp] Review 6833bis

> > What Luigi had suggested was: > Documents that request for a new LISP packet type MAY indicate > a preferred value. > > That fix works for me. Leaving it saying something about section 10.4 is > incorrect. This is in the latest revision. Thanks. Dino

Re: [lisp] Review 6833bis

Are you saying the latest diff file I sent is fine? Dino > On Mar 18, 2018, at 8:45 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: > > No idea how it got to this state. Luigi's suggested fix suffices. > Yours, > Joel > >> On 3/18/18 4:42 PM, Dino Farinacci wro

Re: [lisp] Review 6833bis

(can you request a specific code point from a > registry). > > As best I can tell, it should be removed. > > Yours, > Joel > > On 3/18/18 1:06 PM, Dino Farinacci wrote: >>> Hi All, >>> >>> I’ve read 6833bis document. >>> My few comment

Re: [lisp] Review 6833bis

FYI, I did have that text in there: Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management will need to be resolved so that doing so will be reliable and

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

Tom Herbert wrote: >> On Fri, Mar 16, 2018 at 12:17 PM, Dino Farinacci <farina...@gmail.com> wrote: >>> Yes, understand. But even in your constrained “domain”, there may be just >>> too much state to push to all nodes. Especially in the 5G use-case. It >>>

Re: [lisp] [Ila] LISP for ILA

> The state would need to be sharded. You'd probably need to do this > anyway for mapping-servers or high thoughput Internet facing routers > for which using a cache would be challenging. What LISP-DDT suggests and specs. Dino ___ lisp mailing list

Re: [lisp] [Ila] LISP for ILA

> Detecting that something is under DOS attack is not problem. It’s I do think it is a problem. Because you can’t tell sometimes if it is a high-rate due to high demand from good actors. From the mapping system’s perspective, you don’t know the traffic patterns so you don’t know that if a

Re: [lisp] [Ila] LISP for ILA

a baseline of “normal behavior”. So we can go into frequency-hopping mode when we deviate by %x. Dino > On Mar 16, 2018, at 10:58 AM, Tom Herbert <t...@quantonium.net> wrote: > > On Fri, Mar 16, 2018 at 10:38 AM, Dino Farinacci <farina...@gmail.com> wrote: >>>

Re: [lisp] [Ila] LISP for ILA

> Attackers don't typically set the evil bit in packets and will > otherwise try to make their packets indistiguishable from legitimate > traffic. Can you provide a reference to a specific solution with an > algorithm that is able separate the bad packets from the good packets > wrt the cache.

Re: [lisp] [Ila] LISP for ILA

> Using IPv6 format is something we considered while writing the draft. We went > the LCAF route to have an explicit way to (1) distinguish ILA > Identifiers/Locators from other addresses in the Mapping System, (2) specify > the Identifier/Locator length and (3) include metadata bits. However,

Re: [lisp] [Ila] LISP for ILA

| #+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > On Mar 5, 2018, at 6:23 PM, Tom Herbert <t...@quantonium.net> wrote: > > On Mon, Mar 5, 2018 at 5:00 PM, Dino Farinacci <farina...@gmail.com> wrote: >>> Looking at the map-reply message format, I am concerned about its >>> size. By my count, it's 40 bytes to

Re: [lisp] [Ila] LISP for ILA

> Looking at the map-reply message format, I am concerned about its > size. By my count, it's 40 bytes to provide one record with one > locator where record and locator are 8 bytes. If we need to scale a > system to billions of nodes this overhead could be an issue even if > it's the control

Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt

>> On 5 Mar 2018, at 19:06, Dino Farinacci <farina...@gmail.com> wrote: >> >>> Hi all >>> >>> This document should address all the comments except this one: >>> >>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement

Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt

> > 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 : The Locator/ID Separation Protocol (LISP) > >

Re: [lisp] Quiet period for document publication?

> I already had initiated Last Calls before the freeze for: > draft-ietf-lisp-signal-free-multicast > draft-ietf-teas-rsvp-egress-protection > draft-ietf-teas-rsvp-ingress-protection > I’ve scheduled these for the 3/8 telechat. Due to the heavy load, these may > or may not be reviewed. The

Re: [lisp] RFC 8112

Formally, it is a product of the listed authors. > > Yours, > Joel > > On 2/23/18 1:11 PM, Dino Farinacci wrote: >> I don’t understand why its different than lig. Can you put it in the list? >> Dino >>> On Feb 23, 2018, at 9:55 AM, Joel M. Halpern <j...@joel

Re: [lisp] RFC 8112

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 listed in the RFC list in >> https://datatracker

[lisp] RFC 8112

Chairs, can you check why RFC 8112 is not listed in the RFC list in https://datatracker.ietf.org/wg/lisp/documents/? Thanks, Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] [pim] Fwd: Last Call: (Signal-Free LISP Multicast) to Experimental RFC

Some of those were presented at MBONED/PIM WGs but not all of them. But I also included the ones we presented at the LISP WG. Dino > On Feb 19, 2018, at 1:49 PM, Alvaro Retana <aretana.i...@gmail.com> wrote: > > On February 19, 2018 at 4:34:08 PM, Dino Farinacci (farina...@gmai

Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-09.txt

ld move to informative. > > Ciao > > L. > >> On 14 Feb 2018, at 02:02, Dino Farinacci <farina...@gmail.com> wrote: >> >> Folks, I have been sitting on these changes for a while. It addresses most >> but not all the comments that have been sent to t

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

> On Jan 28, 2018, at 5:57 PM, Albert Cabellos > wrote: > > G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement > Considerations), 18 (Traceroute Consideration) to a new OAM document For the record I don’t support this. It will slow down the process

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

> changes: > > *Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and > Echo-Nonce > *Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3 (hints > from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a response) and > RLOC probin

Re: [lisp] Review 6830bis -08/-09

I’ll send a new -09 update to the list in my reply to Padma’s email. >> >>Client-side: Client-side is a term used in this document to indicate >> a connection initiation attempt by an EID. >> > [Luigi] > As stated for -07. > Following sentence not needed here. (it is specified in

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

>> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and >> ‘identifier of the underlay’ respectively. > > For the RLOC I would put modify the definition as follows: > > Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 > [RFC8200] address of an Egress

Re: [lisp] 6830bis Review

> > On Mon, Jan 15, 2018 at 6:55 PM, Dino Farinacci <farina...@gmail.com> wrote: >>> SMRs and RLOC-probes are control-plane features used by xTRs to be able to >>> run the data-plane. >> >> They are data-plane features that use control-plane mess

Re: [lisp] 6830bis Review

> (Yes, my hats are bouncing.) > I would really like to hear from other WG members about this. It is the WGs > document. The chairs would prefer not to simply use their own judgment. So > to repeat Luigi's plea: speak up. > And if there is silence, then what? Dino

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

t; review the document. I won’t make any other changes until I see your comments. Dino > > L. > > >> On 13 Jan 2018, at 19:30, Dino Farinacci <farina...@gmail.com> wrote: >> >> Here is a -09 proposal to add your requested change C below. All the other >>

Re: [lisp] 6830bis Review

> SMRs and RLOC-probes are control-plane features used by xTRs to be able to > run the data-plane. They are data-plane features that use control-plane messages. No other devices sends an RLOC-probe (or SMR) then an xTR. And the elements of operation are based on the map-cache. Any manipulation

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

> Hi all > > As editor of 6830bis I´d like to confirm or deny the following changes which > I believe have support. Thanks a lot for doing this Albert. This is very helpful. > Please note that I have intentionally ignored minor/editorial changes to help > sync all the participants. I hope

Re: [lisp] [RTG-DIR} RtgDir last call review: draft-ietf-lisp-signal-free-multicast-07.txt

n I saw "RTR" used in the text I had to go back to the terminology section > because otherwise I thought you were just talking about a "Router”. A sign that you have been doing routers (aka RTRs) too long. ;-) Dino > > Les > > > >> -Original Message

Re: [lisp] [RTG-DIR} RtgDir last call review: draft-ietf-lisp-signal-free-multicast-07.txt

> The first use of LCAF (Section 2) should be expanded. > > I find the acronym "RTR" a bit unfortunate for the obvious reason that it > intuitively represents "just a router". I wonder if the authors could Les, I understand your concern here. However, RTR is littered throughout many LISP

Re: [lisp] 6830bis Review

, the data-plane specification. Dino > On Jan 12, 2018, at 3:01 AM, Luigi Iannone <g...@gigix.net> wrote: > > > >> On 11 Jan 2018, at 18:50, Dino Farinacci <farina...@gmail.com> wrote: >> >> Thanks Alberto for your comments. Here is how I break up items i

Re: [lisp] 6830bis Review

consensus to make progress with the docs. > What do you guys think? > > Alberto > > On Wed, Jan 10, 2018 at 6:26 PM, Dino Farinacci <farina...@gmail.com> wrote: >> From my perspective on the situation: >> >> (1) I made changes exactly to text that was requested

Re: [lisp] 6830bis Review

further. I can’t read your minds so I need more of your help. So please put more effort into it. Thanks in advance for your support, Dino > On Jan 10, 2018, at 2:03 AM, Luigi Iannone <g...@gigix.net> wrote: > > Dino, > >> On 9 Jan 2018, at 18:54, Dino Farinacci <

Re: [lisp] 6830bis Review (PLEASE COMMENTS)

Brief reply. The OAM information is necessary for the data-plane. And if LISP-GPE, VXLAN, or any other data plane wants to use their own OAM or use the LISP control-plane differently, it needs to be documented in their data-planes. Hence, why this information is

Re: [lisp] Current changes for draft-ietf-lisp-rfc6830bis-08

nk the proposition of moving text that the chairs proposed is very > reasonable and greatly improve the quality of the specifications and therefore > reduce the risk of misinterpretation and bugs while implementing the protocolS > > > Cheers, > > Damien Saucez > >> O

Re: [lisp] 6830bis Review

rs, > Joel > > On 12/27/17 11:18 PM, Dino Farinacci wrote: >>>> Note, we still care about scalability of any underlay, especially the >>>> Internet core, so we should leave this in. Note, we ARE still solving the >>>> scalability problem. >>&

Re: [lisp] 6830bis Review - scalability

posed Standards without having that fight. And we get to > use a PS for all sorts of interesting and desirable tasks. I agree that the document should not say we are trying to scale the Internet. And I believe it does not say that. Dino > > Yours, > Joel > > On 12/26/17 11:13

Re: [lisp] 6830bis Review

I will comment here before providing a new update and response to Luigi’s latest email. > On Dec 26, 2017, at 5:48 PM, Albert Cabellos > wrote: > > Hi > > Thanks for the review, please find my comments inline. > > I have removed all the comments for which I

Re: [lisp] RFC6830bis and multiprotocol support

are in > 6830bis? > > Can the chairs open a call for adoption in the mailing list, or do we need to > wait the next IETF? > > This might be similar to what Dino proposes below. > > Thanks, > Fabio > > On 12/14/17 9:01 AM, Dino Farinacci wrote: >> I w

[lisp] Fwd: [5gangip] 5G & IP Task Force - was: FW: Re: MINUTES of side meeting in Singapore

be based on (1) above (or > identical) or it could be different. > > Here are the list of people who agreed to serve and contribute in general: > Dino Farinacci, Peter Ashwood (with Arash), Saleem, Tom, and Alex. > This is gratefully acknowledged! > Further volunteers' effort is mo

Re: [lisp] RFC6830bis and multiprotocol support

I would prefer to not merge the two documents. Should we say in RFC6830bis that the R-bit is already allocated but don’t way why and make no reference. If no, I go for option A. Dino > On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: > > His All, > > happy to see so much

Re: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support]

I’ll try to get an update to you before then so it can be easier. Thanks Luigi. Dino > On Dec 14, 2017, at 2:58 AM, Luigi Iannone <g...@gigix.net> wrote: > > > >> On 14 Dec 2017, at 00:02, Dino Farinacci <farina...@gmail.com> wrote: >> >> After I go

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

>>> Another benefit with TCP is congestion control, with UDP if we send a >>> map-register and we don't get an ack then we retry. What if the MS is >>> fully subscribed then this can lead to constant retry. You can impose >>> backoff mechanism but ultimately this would affect convergence. >>

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

RLOC-set data is in the pipeline. Dino > > -Johnson > >> On Dec 6, 2017, at 11:17 AM, Dino Farinacci <farina...@gmail.com> wrote: >> >>> Dino, >>> >>>> LISP (the application), does not know that itself, the xTR, is in sync >&

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

y messages to all the subscribers, then followed by another set of Map-Notifies with the new RLOC-set. That is a lot of (unnecessary) messaging and processing. We have to think about the implications of any one draft on the ENTIRE LISP architecture. It must work efficiently as one holistic

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

> registration protocol, that might be orthogonal to other transport-related > mechanisms. In my experience this has proved to be very effective in > scalability of large LISP deployments, especially with the increased volume > of registration data. I agree it’s a point solution for

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

> draft-kouvelas-lisp-map-server-reliable-transport are looking for > working-group adoption of the draft. The proposed solution replaces the UDP > based control Augments. We cannot remove UDP since there is too much deployment. And TCP is not always needed. And there is startup latency with

Re: [lisp] RFC6830bis and multiprotocol support

I strongly suggest that the proponents for the P-bit do not couple this with IOAM because there is a lot more machinery to be described which may be too late for 6830bis. When RFC 8061 LISP-crypto was written, the authors anticipated the P-bit and hence why the two low-order bits in the flags

Re: [lisp] RFC6830bis and multiprotocol support

the necessary >>>> specifications to support the L2 services proposed in the eid-mobility >>>> draft. >>>> >>>> Victor >>>> >>>> On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <fma...@cisco.com> wrote: >>>> >&g

Re: [lisp] RFC6830bis and multiprotocol support

I’d also add before the last sentence: If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits are set to 0. Dino > On Nov 29, 2017, at 3:07 PM, Fabio Maino <fma...@cisco.com> wrote: > > On 11/29/17 3:05 PM, Dino Farinacci wrote: >> How about this wording F

Re: [lisp] RFC6830bis and multiprotocol support

te the presence of the 8 bit Next > Protocol field encoded as: > > > > Do you think the overall proposed extension makes sense? > > Thanks, > Fabio > > On 11/29/17 2:38 PM, Fabio Maino wrote: >> On 11/29/17 2:36 PM, Dino Farinacci wrote: >&g

Re: [lisp] RFC6830bis and multiprotocol support

> The use of the P-bit is not compatible with the Map-Versioning feature, but > an equivalent function can be specified (if needed) with a Next-Protocol shim > header. I can add text to the LISP-GPE draft to reflect that. Well it could be. Just like you did with the Nonce field. Make the

Re: [lisp] Review of RFC6833bis

t; On Nov 29, 2017, at 10:04 AM, Alberto Rodriguez-Natal >> <rodriguezna...@gmail.com> wrote: >> >> Thanks for the responses Dino. I'll get back to you later this week. >> >> Alberto >> >> On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci <far

Re: [lisp] Nonce in PubSub

> Then I'm afraid that your implementation is not following the current Well there is one of two ways to fix that. :-) > specification. But worry not, we can update -02 with Erik's suggestion > so your implementation and the draft are in sync :) Thanks a bunch. Dino

Re: [lisp] Nonce in PubSub

> I see your point. The draft assumes a security association between the > ITR and the MS in order to authenticate the Map-Notifies. I think this We can’t assume this. That is, a subscriber may not register its EID-prefixes to the same map-server that the EID-prefix it Is Map-Requesting is

Re: [lisp] Review of RFC6833bis

Thanks for the comments. We’ll bring this up in the meeting but I can’t address your comments until next week. Some points: (1) Packets are “control-plane” encapsulated to the Map-Resolver, so the text is correct. (2) The WG had decided at some point to not include the NAT-traversal document

Re: [lisp] draft-ermagan-lisp-nat-traversal question

The TTL in the Map-Register is the TTL returned in Map-Replies. So it is the expiry time for a map-cache entry. Note it is the “Record TTL” in the EID-record which both appear in Map-Register and Map-Reply messages. Dino > On Nov 3, 2017, at 1:35 AM, Albert López wrote: >

Re: [lisp] Review of RFC6830bis

LISP WG, is there any objections to adding this text: There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. For these and other scenarios

Re: [lisp] Review of RFC6830bis

rtsch, B.Sc. Informatics >> <i...@bartschnet.de> wrote: >> >> >> >> Am 27.10.2017 um 06:30 schrieb Dino Farinacci: >>>> I'm not that happy with >>>> >>>> "As the architecture is realized, if a given bit string is

Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00

> -Message d'origine- >> De : Dino Farinacci [mailto:farina...@gmail.com] >> Envoyé : jeudi 19 octobre 2017 15:21 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : lisp@ietf.org list >> Objet : Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-

Re: [lisp] Review of RFC6830bis

I removed it. See a separate email with new diff file and still open issues. Dino > On Oct 26, 2017, at 2:18 AM, Luigi Iannone wrote: > > Personal opinion here... > >> On 25 Oct 2017, at 05:01, Alberto Rodriguez-Natal >> wrote: >>> >> [AR4]

Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00

> Does it clear state what the ETR has to do when it receives a Map-Request > with multiple EIDs? This is what the Record Count field says in RFC6833bis in "4.2. Map-Request Message Format" section: Dino ___ lisp mailing list lisp@ietf.org

Re: [lisp] Review of RFC6830bis

> I'm not that happy with > > "As the architecture is realized, if a given bit string is both an RLOC and > an EID, it must refer to the same entity in both cases". > > In a MESH-architecture the EID of a mobile-node can be the RLOC of a > neighbour mobile-node. I too would like to understand

Re: [lisp] Review of RFC6830bis

> Hi Dino, > > Thanks for your responses. See below for some comments (starting with > [AR2]). On those responses I have not commented, I agree with your > resolution or with your request for WG discussion. See my responses. I’ll post an update to the response email I send to Luigi. >> Working

Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00

> Please see inline. > > Cheers, > Med > >> -----Message d'origine- >> De : Dino Farinacci [mailto:farina...@gmail.com] >> Envoyé : lundi 16 octobre 2017 15:08 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : lisp@ietf.org list >> Objet :

Re: [lisp] Review of RFC6830bis

Thanks Luigi and Alberto for your subsequent comments. > On Oct 19, 2017, at 5:10 AM, Luigi Iannone wrote: > > > Just stating my personal opinion here… I encourage others to provide their opinion as well. I will wait until this weekend to send another update. We need more

Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00

> RFC6830 or your Internet Draft? > [Med] I’m referring to RFC6830 which says the following : > >Record Count: This is the number of records in this Map-Request > message. A record is comprised of the portion of the packet that > is labeled 'Rec' above and occurs the number of

Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

>> It needs the information for table lookups. So how private/trackable are IP >> addresses in packets today? > > Uh really terrible? That's why things like Tor exist. TOR exists because the network layer doesn’t have sufficient security. I’m preaching to the choir. > I'm not sure it's useful

Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

> On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <farina...@gmail.com> wrote: > Let me ask for your opinion Christian (or anyone else for that matter). If a > device is assigned a private/public key-pair and the identifier for the > device is a hash of the public-key, is the

Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00

iple EID-records in a Map-Request. Let’s start there. Dino > > Thank you. > > Cheers, > Med > >> -Message d'origine- >> De : lisp [mailto:lisp-boun...@ietf.org] De la part de Dino Farinacci >> Envoyé : lundi 9 octobre 2017 18:56 >> À : lis

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

See responses below. I cut out text that I didn’t need to respond to. > [Med] I may not look like a pubsub capability, but this is a consequence of > requiring the Map-Resolvers to maintain state for notification purposes. > Maintaining those state may include some extra load on those servers.

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

> Hi Dino, all, > > I do strongly support that pub/sub feature is also possible in LISP. Thanks for the response Med. I think it can be introduced quite easily with the right machinery. > Overloading Map-Request is one way to proceed, but there is also an alternate > approach to define a

Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

> I suggest that could be called idloc (for Identifier-Locator) I would suggest ms-ops as in “mapping system operation”. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

Adding lisp@ietf.org to cc list. How about creating a working group that solely focuses on deployment of a mapping system and does not specify how and where identifiers are allocated? I have made suggestions before that such a working group should be in the ops area. Some examples include and

[lisp] Fwd: WG Review: IDentity Enabled Networks (ideas)

FYI. Dino > Begin forwarded message: > > From: The IESG > Subject: WG Review: IDentity Enabled Networks (ideas) > Date: September 29, 2017 at 9:13:28 AM PDT > To: "IETF-Announce" > Cc: id...@ietf.org > Reply-To: i...@ietf.org > > A new IETF WG

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

> On Sep 19, 2017, at 9:19 PM, Alberto Rodriguez-Natal > wrote: > > That sounds reasonable Joel. We will work on an extended description and get > back to the list. The big question is if the pubsub draft should be referenced from 6833bis? Has the same issues as

[lisp] Any status on resolving issues with draft-ietf-lisp-sec-12?

I am wondering since its been stuck for 110 days. Albert? I think ball was in your court last? Dino >> From: Albert Cabellos [mailto:albert.cabel...@gmail.com] >> Sent: Thursday, August 10, 2017 12:30 AM >> To: BRUNGARD, DEBORAH A >> Cc: Manav Bhatia ;

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

> Correct, what is of interest is to have some sense of the likelihood of the > mapping received changing and allow the ITR to check again. We are looking at > the NMR as one way to indicate back to the ITR the nature Sounds like one way is using draft-rodrigueznatal-lisp-pubsub-00. Then the

Re: [lisp] Call for WG Adoption of LISP Anonymity [draft-farinacci-lisp-eid-anonymity-02.txt]

> Authors are invited to submit a new version of the document named: > draft-ietf-lisp-eid-anonymity-00.txt Done. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp

[lisp] Proposal: LISP for the Mobile Network

SDOs, for your consideration: https://datatracker.ietf.org/doc/draft-farinacci-lisp-mobile-network/ Thanks, Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Questions on draft-ietf-lisp-eid-mobility-00.txt

Thanks for the question Yue. I included the diagram so others can follow easier: > How the 1st sequence of the packet flow (1st paragraph on Page 7) can be > achieved please? Device 1 is sending packets no matter where it is connected. So it will use its default router to send packets. The

Re: [lisp] Call for WG Adoption of Vendor Specific LCAF [draft-rodrigueznatal-lisp-vendor-lcaf-00.txt]

I support draft as an WG document. Dino > On Jul 26, 2017, at 2:41 AM, Luigi Iannone wrote: > > Hi All, > > During the 99th IETF authors of the document > draft-rodrigueznatal-lisp-vendor-lcaf-00.txt > [https://tools.ietf.org/html/draft-rodrigueznatal-lisp-vendor-lcaf-00] >

Re: [lisp] [ERRATA] Call for WG Adoption of LISP Anonymity [draft-farinacci-lisp-eid-anonymity-02.txt]

I support making draft WG document. Dino > On Jul 26, 2017, at 4:16 AM, Luigi Iannone wrote: > > The call ends August 10th 2017 ! > > Luigi > > >> On 26 Jul 2017, at 11:41, Luigi Iannone wrote: >> >> Hi All, >> >> During the 99th IETF authors of the

[lisp] lisp-geo and lisp-name-encoding

Folks, I would like to get more comments on the following drafts: https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/ https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/ There are multiple implementations of both drafts and products shipping based on them but the WG

Re: [lisp] Call for WG Adoption of document draft-farinacci-lisp-name-encoding-03.txt

Support WG adoption. Dino > On Jun 28, 2017, at 8:03 AM, Luigi Iannone wrote: > > Hi All, > > Authors of the document draft-farinacci-lisp-name-encoding-03.txt > [https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/] > asked for WG adoption. > > This message

Re: [lisp] Call for WG Adoption of document draft-farinacci-lisp-geo-03.txt

Support WG adoption. Dino > On Jun 28, 2017, at 8:03 AM, Luigi Iannone wrote: > > Hi All, > > Authors of the document draft-farinacci-lisp-geo-03.txt > [https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/] > asked for WG adoption. > > This message begins the two weeks

Re: [lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

> You mean that if all communications went from ITR->RTR->ETR then > there would be no packet loss? That would be a dogleg path where > you would really rather do ITR->ETR. You put the RTR in the core so its on path for most flows. > What I am suggesting is to start out with a dogleg path, then

Re: [lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

Right, I got that. Dino > On Jun 15, 2017, at 9:22 AM, Templin, Fred L > wrote: > > Dino, > > An important clarification: > >> Rerouting from a slower path to a faster path can happen anywhere in the >> network and at any time. > > Slower/faster is not the

Re: [lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

> Thanks, I read the document. It looks like the approach focuses on trying to > hit > a moving target, and an airplane might be a good example use case. That is > good, > but not exactly the case I was concerned about. I am concerned about an > airplane You were concerned about the “first

Re: [lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

> LISP’ers, Fred, thanks for the email. Sorry for the delay on my response. > Since the closing of the Routing Research Group (RRG), I have been focused > on furthering the development of my own technologies that began there, > and really haven't paid much attention to LISP - even to the point

Re: [lisp] Call for WG Adoption of document draft-farinacci-lisp-predictive-rlocs-02.txt

Support. Dino > On May 19, 2017, at 2:06 AM, Luigi Iannone wrote: > > Hi All, > > Authors of the document draft-farinacci-lisp-predictive-rlocs-02.txt > [https://datatracker.ietf.org/doc/draft-farinacci-lisp-predictive-rlocs/] > asked for WG adoption. > > This message begins

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

Great, I’ll post new version today. Dino > On May 9, 2017, at 10:23 PM, <mohamed.boucad...@orange.com> > <mohamed.boucad...@orange.com> wrote: > > Hi Dino, > > Looks good to me. Thank you. > > Cheers, > Med > > De : Dino Farinacci [mailto:fari

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

s no such registry. Are you referring > to the old "LISP Key ID Numbers". In such case, the text should make it clear > what action are you requiring from IANA. > > > Cheers, > Med > >> -Message d'origine- >> De : Dino Farinacci [mailto:fari

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

to the IANA section to ask IANA to update the references > for these entries to the bis document. > > Thank you. > > Cheers, > Med > > De : lisp [mailto:lisp-boun...@ietf.org] De la part de Dino Farinacci > Envoyé : jeudi 4 mai 2017 20:57 > À : lisp@ietf.org list >

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

> 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 > >> On 5/4/17 2:57 PM, Dino Farinacci wrote: >> Since the reference in RF

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

> Hi Dino, > > I still have comments to this text: > > “Values in the "For Future Assignment" range can be assigned according > to procedures in [RFC5226]. » Yes it does and it was text added to get RFC6830 published. > - replace RFC5226 with RFC8113. Pointing to RFC5226

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

> I would remove the “Not Assigned” from the table because your introduction > text is about “codes assigned by this document”. > I would add a note for asking IANA to formally assign type 5. See new update to include comment above. I’ll post tomorrow (Thu noon PDT time) if there are no

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

> Hi Dino, > > This is better. Thanks. > > I would remove the “Not Assigned” from the table because your introduction > text is about “codes assigned by this document”. > I would add a note for asking IANA to formally assign type 5. I will add text to new 7.1 section I added. > BTW, did you

<    1   2   3   4   5   6   7   8   9   >