Re: [lisp] [IANA #1264435] expert review for draft-ietf-lisp-pubsub (lisp-parameters)

[Albert Cabellos]

Same here,

Albert

> On 18 Jan 2023, at 23:09, Dino Farinacci  wrote:
> 
> 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] Call for adoption for LISP Geo-Coordinate Use-Cases

[Albert Cabellos]

Hi

I read the document and I support it. 

Albert

> On 29 Oct 2022, at 18:53, Dino Farinacci  wrote:
> 
> 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

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP Specifications Published!! :-)

[Albert Cabellos]

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

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

[Albert Cabellos]

Hi

I´ve posted -29 following your comments, please find inline specific responses:

On Thu, Jul 9, 2020 at 6:26 AM Benjamin Kaduk via Datatracker
 wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lisp-rfc6833bis-27: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/
>
>
>
> --
> DISCUSS:
> --
>
> (1) The -27 brought back the "MUST" for HMAC-SHA256-128 in Section 5.6 per
> my ballot on the -26, but left unchanged section 9, so we still have a
> SHOULD vs. MUST inconsistency w.r.t. implementing
> HMAC-SHA256-128+HKDF-SHA256.  (I would of course prefer the same
> resolution of the inconsistency that Roman does, but have forgotten to
> what extent we have to defer to the deployed reality.)
>

>From a deployment reality perspective, I think that this makes sense:

  Implementations of this specification MUST implement
HMAC-SHA-256-128 and SHOULD implement HMAC-SHA256-128+HKDF-SHA256

Now it is consistent across the document. Please let me know your view on this.

>
> (2) It looks like the update in Section 5.7 is attempting to address my
> point about only terminating Map-Notify retransmission when the
> authentication data of the Map-Notify-Ack validates, but the added text
> is either misplaced or malformed.  Perhaps
>
> CURRENT:
>The Map-Notify-Ack message has the same contents as a Map-Notify
>message.  It is used to acknowledge the receipt of a Map-Notify and
>for the sender to stop retransmitting a Map-Notify with the same
>nonce and the authentication data validates.  [...]
>
> NEW:
>The Map-Notify-Ack message has the same contents as a Map-Notify
>message.  It is used to acknowledge the receipt of a Map-Notify and,
>once the the authentication data is validated, allows for the
>Map-Notify sender to stop retransmitting a Map-Notify with the same
>nonce. [...]
>

Changed, thanks.

> (3) I think that Eric Rescorla's concern about a misbehaving ETR being
> able to prevent an ITR from learning that the ETR is no longer the
> appropriate ETR for a given prefix remains unaddressed.  I wrote up a
> longer description at
> https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0/
> but in short, we only require the ITR to send its Map-Request through
> the mapping system (vs. directly to the ETR) when SMR is sent from an
> address not in the current mapping data for that prefix -- if the SMR is
> sent from an address in the current mapping data, we allow sending
> Map-Request directly to the ETR, outside the mapping system.  I don't
> see a mechanism that guarantees that such a "revocation" event is
> noticed by the ITR.
>

Updated the section, now all SMR-invoked Map-Requests MUST be sent
through the Mapping System (This is what deployments are doing):

  An SMR message is simply a bit set in a Map-Request message.
  An ITR or PITR will send a Map-Request (SMR-invoked
Map-Request) when they receive an SMR
  message. While the SMR message is sent through the
data-plane, the SMR-invoked Map-Request
  MUST be sent through the Mapping System (not directly).


> (4) The specification of the MAC+KDF algorithms doesn't seem detailed
> enough to be implementable.  RFC 4868 is attempted to be used as a
> reference for both HMAC-SHA256-128 (er, and the one-character-off
> HMAC-SHA-256-128) and HKDF-SHA2562 (note spurious final '2'), but I
> think it can only work as a reference for the MAC algorithm.  Presumably
> we need RFC 5869 or such for the KDF part
>

Fixed, thanks.


> (5) This is probably my fault, but we're missing a step with how we
> describe the Map-Notify/Map-Notify-Ack per-message authentication.
> Specifically, while we do say that the authentication data needs to be
> recomputed each time, we don't clearly state that this is because the
> correct per-message key is different, because we are using a different
> 's' input to the KDF function for the different messages.  In line with
> the "Map-Register Authentication" used for Map-Register, this would
> presumably be "Map-Notify Authentication" and "Map-Notify-Ack
> Authentication", but neither of those strings appear in this document.
> We might be able to localize the change to Section 5.6, akin to
>
> OLD:
>   4:  The derived per-message key is computed as: per-msg-
>   key=KDF(nonce+s+PSK[Key ID]).  Where the nonce is the value in
>   the Nonce field of the 

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

[Albert Cabellos]

Hi

I´ve posted -28 updating the text following your comments, please find
inline additional information:

https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/


On Tue, Jul 7, 2020 at 12:52 AM Martin Duke via Datatracker
 wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-lisp-rfc6833bis-27: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/
>
>
>
> --
> DISCUSS:
> --
>
> Two issues rise to DISCUSS level, IMO:
>
> Sec 5.7. Is the intent that the Map-Notifies are only retransmitted if they 
> are
> unsolicited? If not, repeated Map-Registers could result in a storm of
> Map-Notifies.
>

6833bis specs that Map-Notifies are retransmitted when Map-Notify-Ack
are not received.

The behaviour of unsolicited Map-Notifies are NOT spec’ed in 6833bis,
this is specified in draft-ietf-lisp-pubsub

What 6833bis specs -per a review by Mirja- is that if an unsolicited
Map-Notify is sent, then it will follow the guidelines of RFC8085


> Sec 7.1. I very well may have missed something, but it doesn't look like the
> Map-Request is authenticated. So how can the ETR safely update its Map Cache
> based on the information in the Map-Reply?
>

The Map-Request is just a query to an EID, and as such it is not authenticated.
The Map-Reply carries the response to such query, an EID-to-RLOC
mapping. This query is authenticated.  The Map-Cache is updated based
on the received EID-to-RLOC mapping.

>
> --
> COMMENT:
> --
>
> Sec. 5. Please clarify that the 576B and 1280B limits include the entire IP 
> packet.

Changed, thanks.

>
> Sec 5.4. Does the "weight" refer to the percentage of packets or bytes?
>

This is already clarified (IMO): "Weight is encoded as a relative
weight of total unicast packets that match the mapping entry."

> Sec 5.5. The first sentence should suggest that the Map Reply could return 
> multiple EID prefixes.

The first sentence reads “A Map-Reply returns an EID-Prefix with…”,
IMHO it is already clear. Thanks!

>
>
>
> ___
> 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] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

[Albert Cabellos]

Hi Martin

Just posted -34 per your comments:

https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-34

1) Removed duplicate paragraph in section 7
2) Added the following sentence for clarification of what happens when N=0
and V=0: "*Finally, when both the N and V-bit are not set (N=0, V=0), then
both the Nonce and Map-Version fields are set to 0 and ignored on receipt*"
3) Removed the IPv4-only requirement in section 7.2. Please note that this
is in -35 since I missed it in the first place.
4) Added the following paragraph (yours, verbatim) at the end of section
7.2:

*Please note that [RFC1191] and [RFC1981], which describe the use of ICMP
packets for PMTU discovery, can behave suboptimally in the presence of ICMP
black holes or off-path attackers that spoof ICMP. Possible mitigations
include ITRs and ETRs cooperating on MTU probe packets ([RFC4821],
[I-D.draft-ietf-tsvwg-datagram]), or ITRs storing the beginning of large
packets to verify that they match the echoed packet in ICMP Frag
Needed/PTB.*

Albert


On Fri, Aug 14, 2020 at 12:17 AM Martin Duke 
wrote:

> As promised, here are my reconsidered thoughts about Section 7.2:
>
> 1) as agreed before, delete the restriction to IPv4 and restore the other
> references to ICMPv6 in draft-31.
>
> 2) There is not an IETF consensus document that describes what I feel to
> be the most secure way to do tunnel PMTU management. So the current design
> is acceptable; however, there should be some warning about the robustness
> issues here. Example text:
>
> "Please note that [RFC1191] and [RFC1981], which describe the use of ICMP
> packets for PMTU discovery, can behave suboptimally in the presence of ICMP
> black holes or off-path attackers that spoof ICMP. Possible mitigations
> include ITRs and ETRs cooperating on MTU probe packets ([RFC4821],
> [I-D.draft-ietf-tsvwg-datagram]), or ITRs storing the beginning 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, Aug 6, 2020 at 6:28 PM Joel M. Halpern 
> wrote:
>
>> Exploring Martin's second comment, I looked at section 7.2 of the draft.
>>   I do not see any obvious reason why this section is restricted to
>> IPv4.  If there is a reason, we need to state it.  If there is no
>> reason, we should allow it for the v6 case as well.
>>
>> Yours,
>> Joel
>>
>> On 8/6/2020 6:24 PM, Martin Duke wrote:
>> > Hi Joel,
>> >
>> > I'm realizing that we may not have a consensus document that provides
>> > good guidance on how to proceed. I'm going to consult with a couple of
>> > SMEs and come up with a reasonable recommendation. This shouldn't take
>> > any more than a couple of days.
>> >
>> > However the "IPv4 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 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 about the packets it has sent in the tunnels.
>> > As these are low-state tunnels, and as the packets are those
>> > provided by
>> > the sources behind the ITR, I doubt that we can use PLPMTUD,
>> although I
>> > would be happy to be given enough information to find I am wrong
>> > about that.
>> >
>> > I am somewhat confused as to what you would have us do.
>> > Yours,
>> > Joel
>> >
>> > On 8/6/2020 4:35 PM, Martin Duke wrote:
>> >  > Hi Albert,
>> >  >
>> >  > thanks for the edits, and sorry for the delay! We're not quite
>> > there on
>> >  > a few of the items:
>> >  >
>> >  > Though first, there is now a duplicate paragraph in Section 7.
>> > Please
>> >  > delete one.
>> >  >
>> >  > On Fri, Jul 31, 2020 at 5:43 AM Albert Cabellos
>> >  > mailto:albert.cabel...@gmail.com>
>> > <mailto:albert.cabel...@gmail.com
>> > <mailto:albert.cabel...@gmai

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

[Albert Cabellos]

Hi,

 Thanks for your comments, we have updated the draft accordingly (-33):

 https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/


Find below the specific changes and responses to your comments:

On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker 
wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-lisp-rfc6830bis-32: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
>
>
>
> --
> DISCUSS:
> --
>
> Having read this document front to back for the first time, I found it
quite
> hard to figure out what can actually safely done over the public
internet, and
> what can be only be done in trusted environments. I realize that this is
> probably because the no-internet provisions entered late in the game. If
it
> were my document, I might reorganize it to make the distinction more clear
> (i.e. present the internet-safe dataplane spec and then have additional
> sections about insecure add-ons). That said, at this stage in the game
I'd be
> happy to have a new section that clarified what is what. For example
(assuming
> I'm reading it correctly, which is my point)
>
> NEW:
> "
> Section 4 and a half. Deployment on the Public Internet
>
> Many of the mechanisms in this document are intended for deployment in
> controlled, trusted environments, and are insecure for use over the public
> internet. In particular, on the public internet xTRs:
>
> * SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;
>
> * SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);
>
> * SHOULD NOT use any data plane methods described in Section 10 for
Routing
> Locator Reachability, instead relying solely on control plane methods;
>
> * SHOULD NOT use any data plane methods described in Section 13 to update
the
> EID-to-RLOC mapping, instead relying solely on control plane methods.
>
> "
>
> END
>
> Perhaps my text is inaccurate, but something to that effect would be very
> helpful.
>

We have added -almost verbatim- this to the following new section (section
4.1):

4.1.  Deployment on the Public Internet
   Several of the mechanisms in this document are intended for
   deployment in controlled, trusted environments, and are insecure for
   use over the public Internet.  In particular, on the public internet
   xTRs:
   o  MUST set the N, L, E, and V bits in the LISP header (Section 5.1)
  to zero.
   o  MUST NOT use Locator-Status-Bits and echo-nonce, as described in
  Section 10 for Routing Locator Reachability.  Instead MUST rely
  solely on control-plane methods.
   o  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
  as described in Section 13 to update the EID-to-RLOC Mappings.
  Instead relying solely on control-plane methods.



>
> Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits
are
> zero?
>

There is no field then.

>
> Sec 7.2 The stateful MTU design does not incorporate any security measures
> against ICMP spoofing. At the very least, the ITR needs to make sure that
some
> fields in the outer IP and UDP headers are hard to guess, and that this
> information is stored to verify that the ICMP message came from on-path.
If
> this is not possible, the design is not safe to use over IPv4.  If
> hard-to-guess information is not available to be stored deeper in the
packet,
> then it is not safe over IPv6 either.
>

The source UDP port is random. We have therefore added the following
statement at the beginning of section 7.7:

   An ITR stateful solution to handle MTU issues is described as follows,
this solution can only be used with IPv4-encapsulated packets:

>
> Sec 7.2 There is a fourth situation which can arise. If the ETR receives
an
> ICMP packet from an EID in its network. I have a couple of questions
about what
> should happen in this case:
>

In this case the EID is locally attached to the xTR. Therefore, the xTR has
a locally configured MTU to reach the EID. So what is written in the
section already covers this scenario.

>
> - How is this communicated to the sender of the flow that triggered the
> message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the
source
> EID, both, or neither?
>
> - Is the ETR responsible for enforcing the MTU to that EID for subsequent
flows?
>
> Sec 9. I don't understand what this sentence means:
> "The client-side ITR controls how traffic is returned and can alternate
using
> an 

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

[Albert Cabellos]

Hi,

Thanks for your comments, we have updated the draft accordingly (-28):

https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/


Find below the specific changes and responses to your comments:

On Wed, Jul 8, 2020 at 12:04 AM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-lisp-rfc6830bis-32: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
>
>
>
> --
> DISCUSS:
> --
>
> ** Section 1.1. The applicability statement of “large set of cooperating
> entities seeking to communicate over the public Internet or other large
> underlay IP infrastructures” seems inconsistent with many of the protocol
> mechanics described.  Specifically, most of the capabilities in the LISP
header
> (Locator-Status-Bits, Echo-nonce mechanism, Map-Versioning, Instance ID)
and
> the “Gleaning mechanism” are explicitly noted as not being suitable for
> Internet use.  This section needs to be explicit that only a subset of the
> protocol is suitable for the Internet.  Likewise, it should be clearer
about
> what is assumed elements of the closed network are trusted for what
particular
> behaviors.
>

 We have added this to the following new section (section 4.1):

4.1.  Deployment on the Public Internet
   Several of the mechanisms in this document are intended for
   deployment in controlled, trusted environments, and are insecure for
   use over the public Internet.  In particular, on the public internet
   xTRs:
   o  MUST set the N, L, E, and V bits in the LISP header (Section 5.1)
  to zero.
   o  MUST NOT use Locator-Status-Bits and echo-nonce, as described in
  Section 10 for Routing Locator Reachability.  Instead MUST rely
  solely on control-plane methods.
   o  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
  as described in Section 13 to update the EID-to-RLOC Mappings.
  Instead relying solely on control-plane methods.



>
> ** Section 16. Per “Locator-Status-Bits, echo-nonce and map-versioning
SHOULD

> NOT be used over the public Internet and SHOULD only be used in trusted
and

> closed deployments” -- not disagreement.  However, under what
circumstances
> would they be used on the internet to warrant a SHOULD NOT instead of a
> stronger MUST NOT?
>

Gleaning, Locator-Status-Bits, echo-nonce and Map-Versioning elevated to
MUST NOT.

> ** Section 8.  Per “Participants within a LISP deployment must agree on
the
> meaning of Instance ID values.  The source and destination EIDs MUST
belong to
> the same Instance ID.”  Could parties agree that the Instance ID is
802.1Q tags
> and send those across the internet?  Recommend stronger cautionary
language on
> using Instance ID.
>

We don´t want to specifically restrict communications between different
Instance IDs, this is up to the deployer. Yes, Instance ID can be used to
carry 802.1Q tags, this is an example stated in the document.

>
> --
> COMMENT:
> --
>
> Thank you for being responsive to the prior security feedback from the
SECDIR
> (and thanks to Kyle Rose for performing it) and Security ADs in the
return of
> this document to the telechat.
>
> I support Martin Duke’s DISCUSS position and endorse the creation of a
> dedicated section covering which protocol features should not be used on
the
> internet.
>
> **  Section 4.0.  Per “… this document recommends that a maximum of two
LISP
> headers …”, should a normative RECOMMENDED be used here instead?
>

Changed, thanks


> ** Section 5.3. Per “However, the same nonce can be used for a period of
time
> when encapsulating to the same ETR.”, should this be bounded, even
> qualitatively?
>

I have removed this sentence, so the same nonce can not be used when
encapsulating to the same ETR.

> ** Section 9.
>   A
>   "gleaned" Map-Cache entry is only stored and used for a few
>   seconds, pending verification.  Verification is performed by
>   sending a Map-Request to the source EID (the inner-header IP
>   source address) of the received encapsulated packet.
>
> -- Is there any more precision that could be provided about the cache
lifetime
> beyond “a few seconds”
>
> -- Should normative language be provided that this cache should be aged
and
> verification performed?

Changed to:

 “A 

[lisp] Wireguard and LISP [Was: Virtual meeting]

[Albert Cabellos]

Hi all

I´d like to discuss the following topic.

We have been prototyping a LISP-based control plane for Wireguard [1] using
the Open Overlay Router implementation [2].

Wireguard is disrupting the field of VPNs by providing an easy-to-use,
high-performance and mobility-aware VPNs. Wiregard aims to replace
traditional IPsec and TLS-based VPNs, and it is open-source and available
in the Linux Kernel.

Wireguard does not have a control-plane, this means that Wireguard nodes
need to be manually configured before being able to exchange packets.
Manual configuration typically involved provisioning public keys using
out-of-band mechanisms. In this context, we have architected and prototyped
a control-plane for Wireguard using LISP, this enables automatic and secure
retrieval of public keys using LISP.

This raises -hopefully- interesting questions, how should LISP support
multiple data-planes? In this context Wireguard can be seen just as another
data-plane. Additionally, Wiregard provides a secure data-plane, can we
learn something from them?

Albert

--

[1] https://www.wireguard.com
[2] https://openoverlayrouter.org

-- Forwarded message -
From: Joel M. Halpern 
Date: Tue, Mar 10, 2020 at 10:44 PM
Subject: [lisp] Virtual meeting
To: lisp@ietf.org 


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 list.  Indication that there are things worth
discussing.

Yours,
Joel

___
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] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)

[Albert Cabellos]

Hi Mirja

Thank you very much for your comments and getting back to us again. We have
been discussing them internally and you can find below specific proposed
changes on the document that hopefully address them.

Please let me know if you agree with them, once this is finished I´ll send
a similar reply for your COMMENTS. Once all the comments are done I´ll send
a diff for your review.

On Tue, Sep 11, 2018 at 5:02 PM Mirja Kühlewind  wrote:
>
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-lisp-rfc6833bis-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/
>
>
>
> --
> DISCUSS:
> --
>
> 1) Versioning and backward compatibility
>
> Section 5.2 says: "Support for requesting multiple EIDs in a single
Map-Request
>   message will be specified in a future version of the protocol."
> However, there is no versioning mechanism for this protocol specified.
How is
> versioning supposed to work?
>
> Further given there is no new version, I wonder if the changes as
outlined in
> section 10 are all backward-compatible? Especially for the introduction
of the
> Message-Notify-Ack message, I guess there is no problem if a server sends
it,
> however, as the sender of the Message-Notify message might not know if the
> other end supports sending of the Message-Notify-Ack it can't rely on it.
This
> should be further discussed in the doc! Or is there another strategy to
achieve
> backward compatibility?
>

There is no support for requesting multiple EID and none of the use-cases
have this requirement. I suggest to remove the text.

>
> 2) Size and MTU
>
> As outlined in the TSV-ART review (Thanks Colin!) this document does not
> discuss fragmentation or Path MTU discovery. RFC8085 recommends to either
> perform Path MTU discovery or limit the message to 576 bytes for IPv4 or
1280
> bytes for IPv6 (minus any static header). As this seems to be an
appropriate
> size for LISP messages, I would recommend this approach. Relying on IP
> fragmentation (as indicated in the reply to the TSV-ART review) is not
> recommended by RFC8085 as this would lead to IP packet without a UDP
header, in
> the case of LISP, which can cause problem and loss when NATs are
involved. In
> any case the chosen approach needs to be further discussed in the doc.
>

RFC8085 states that:

Although most UDP applications are expected to follow these guidelines,
there do exist valid reasons why a specific application may decide not to
follow a given guideline.  In such cases, it is RECOMMENDED that
application designers cite the respective section(s) of this document in
the technical specification of their application or protocol and explain
their rationale for their design choice.


Our rationale is the following one, I suggest to include it on the spec:

LISP is expected to be deployed by cooperating entities communicating over
underlays. Deployers are expected to set the MTU according to the specific
deployment guideline to prevent fragmentation. For deployments not aware of
the underlay restrictions on path MTU, it is RECOMMENDED to default to the
guidelines outlined in RFC8085.


> 3) Rate-limiting and congestion control
>

I suggest to state the following rate-limiters, as specified by RFC8085:

Map-Requests MUST be rate-limited, it is RECOMMENDED that a Map-Request for
the same EID-Prefix be sent no more than one packets per 3 seconds.

Map-Reply and SMR MUST be rate-limited, it is RECOMMENDED that a
Map-Request for the same EID-Prefix be sent no more than one packets per 3
seconds to the same requesting router.

Map-Register messages are sent periodically from an ETR to a Map-Server
with a suggested interval between messages of one minute, MUST not be sent
more than one packet per 3 seconds.


Additional clarifications below:

>
> Sec 5.3: "Map-Requests MUST be rate-limited.  It is RECOMMENDED that a
Map-
>Request for the same EID-Prefix be sent no more than once per second."
> As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually
> recommends to not send more the one packet per 3 seconds, and that is a
> restriction for all traffic not on a per-receiver base, or implement
congestion
> control. This limit is meant to not only protect the receiver but also the
> network from overloading. Why do you use a smaller interval here? Also if
> (appropriate) rate limiting is used, this should either be a MUST or more
> explanation when it is okay to use a 

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

[Albert Cabellos]

Hi

Thanks for the help. I was suggesting to change the references from
6830/6833 to 6830bis/6833bis, not to speed it up.

If it is doable to wait for the bis documents and then change the
references to the bis versions then I´m all for it.

Albert

On Wed, Sep 12, 2018 at 12:01 AM BRUNGARD, DEBORAH A  wrote:
>
> If we want to get lisp-intro done now, we should leave the reference to 
> RFC6830. If change to the bis, we need to wait until they are published as 
> they also would be listed normatively.
>
> -Original Message-
> From: Dino Farinacci 
> Sent: Tuesday, September 11, 2018 5:14 PM
> To: BRUNGARD, DEBORAH A 
> Cc: Albert Cabellos ; lisp@ietf.org list 
> 
> Subject: Re: [lisp] Fwd: Alvaro Retana's No Objection on 
> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)
>
> > I don’t see lisp-sec as essential to implementing lisp-intro. I don’t know 
> > why it was listed as normative? To me, it is providing additional 
> > information.
>
> I agree LISP-SEC is additional information for an introductory document. You 
> bring up a good point.
>
> > If the working group agrees, I can check with the RFC-Editor if can move 
> > lisp-security to informative. I think the change will only need author and 
> > AD approval. Does anyone have any concerns? Or is lisp-security “almost 
> > done” and should continue to wait?
>
> I agree with your proposal. But have another question. If we update the 
> lisp-intro to move this reference to Informative, do you at the same time 
> change all occurences of 6830/6833 to the bis document equivalents or do you 
> want to push lisp-intro through?
>
> I would say go for the latter since the information in 6830/6833 has not 
> changed when shuffling sections around into 6830bis/6833bis. So Albert, the 
> information in RFC6830 is not obsoleted but the document may be.
>
> What do you think?
>
> Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Albert Cabellos]

Hi

I am not familiar with all the IETF procedures, but lisp-intro has been
waiting for a missing reference for 1000+ days and the day it will become
RFC it will be referencing an obsolete document.

I think that we should make it right, if someone can shepherd me on what to
do I´ll be happy to work on it.

Albert

On Tue, Sep 11, 2018 at 6:37 PM Dino Farinacci  wrote:

> Right now there is no circular dependency. To summarize:
>
> (1) RFC6830 does not point to 6830bis or lisp-intro.
> (2) lisp-intro points to RFC6830.
> (3) 6860bis needs to point to RFC6830.
>
> Let’s please don’t change any this. Let’s not make this more complciated
> then it needs to be and let’s not confuse people, especially the authors.
> ;-)
>
> Dino
>
>
> > On Sep 11, 2018, at 9:29 AM, Alvaro Retana 
> wrote:
> >
> > On September 11, 2018 at 9:50:29 AM, Joel M. Halpern (
> j...@joelhalpern.com) wrote:
> >
> > Hi!
> >
> >> 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 alreay blocked by documents which depend upon those.)
> > The reference would still be circular: rfc6830bis would point at
> lisp-introduction for architecture details, and that would point back here.
> >
> > If lisp-introduction was just that (an introduction) and the details
> were in rfc6830 to start with…. Maybe the easy fix is to just not point to
> lisp-introduction from rfc6830bis, because the details should be here (and
> rfc6833bis) already.
> >
> > s/Finally, [I-D.ietf-lisp-introduction] describes the LISP
> architecture.//
> >
> > Alvaro.
> >
> >
> >
> >>
> >>
> >> Yours,
> >> Joel
> >>
> >> On 9/10/18 11:27 PM, Dino Farinacci wrote:
> >> > If you guys have source for the intro doc, I could point it to bis
> >> > documents?
> >> >
> >> > Dino
> >> >
> >> >
> >> > Begin forwarded message:
> >> >
> >> >> *Resent-From:*  alias-boun...@ietf.org>>
> >> >> *From:* Alvaro Retana  >> >> >
> >> >> *Date:* September 10, 2018 at 2:22:21 PM PDT
> >> >> *Resent-To:* farina...@gmail.com ,
> >> >> vince.ful...@gmail.com ,
> d...@1-4-5.net
> >> >> , darle...@cisco.com
> >> >> , acabe...@ac.upc.edu
> >> >> 
> >> >> *To:* "The IESG" mailto:i...@ietf.org>>
> >> >> *Cc:* draft-ietf-lisp-rfc6830...@ietf.org
> >> >> , Luigi Iannone
> >> >> mailto:g...@gigix.net>>, lisp-cha...@ietf.org
> >> >> , lisp@ietf.org 
> >> >> *Subject:* *Alvaro Retana's No Objection on
> >> >> draft-ietf-lisp-rfc6830bis-16: (with COMMENT)*
> >> >>
> >> >> Alvaro Retana has entered the following ballot position for
> >> >> draft-ietf-lisp-rfc6830bis-16: No Objection
> >> >>
> >> >> When responding, please keep the subject line intact and reply to all
> >> >> email addresses included in the To and CC lines. (Feel free to cut
> this
> >> >> introductory paragraph, however.)
> >> >>
> >> >>
> >> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> >> for more information about IESG DISCUSS and COMMENT positions.
> >> >>
> >> >>
> >> >> The document, along with other ballot positions, can be found here:
> >> >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
> >> >>
> >> >>
> >> >>
> >> >>
> --
> >> >> COMMENT:
> >> >>
> --
> >> >>
> >> >> Thanks for the work on this document!
> >> >>
> >> >> I have some relatively minor comments/nits:
> >> >>
> >> >> (1) §18: s/RFC8060/RFC8061
> >> >>
> >> >> (2) §1: "Finally, [I-D.ietf-lisp-introduction] describes the LISP
> >> >> architecture."  First of all, it would seem to me that the
> >> >> Architecture should
> >> >> be a Normative reference...but I-D.ietf-lisp-introduction says that
> it
> >> >> "is used
> >> >> for introductory purposes, more details can be found in RFC6830, the
> >> >> protocol
> >> >> specification."  This document obsoletes rfc6830...so it seems to me
> >> >> that there
> >> >> is a failed circular dependency.
> >> >>
> >> >> (3) References to rfc2119/rfc8174 and rfc8126 should be Normative.
> >> >>
> >> >>
> >>
> >> ___
> >> 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] WG Last Call for draft-ietf-lisp-vendor-lcaf

[Albert Cabellos]

Support

Albert

On Fri, Jul 20, 2018 at 4:59 AM Jordi Paillissé Vilanova 
wrote:

> Support
>
> Jordi
>
> El 20/07/18 a les 07:32, Albert López ha escrit:
>
> +1
>
> On 19/7/18 23:35, Marc Portoles Comeras (mportole) wrote:
>
> I also support handing this document to the AD
>
>
>
> *From: *lisp   on behalf of
> Luigi Iannone  
> *Date: *Friday, July 6, 2018 at 3:06 AM
> *To: *"lisp@ietf.org list"  
> 
> *Cc: *"lisp-cha...@ietf.org"  
> 
> *Subject: *[lisp] WG Last Call for draft-ietf-lisp-vendor-lcaf
>
>
>
> Folks,
>
>
>
> As Alberto mentioned in a previous mail, in London there was consensus to
> move forward draft-ietf-lisp-vendor-lcaf [
> https://tools.ietf.org/html/draft-ietf-lisp-vendor-lcaf-02] (after the
> few fixes that I asked).
>
>
>
> Fixes are done, hence, this email starts the usual two weeks WG Last Call,
> to end July 20th, 2018.
>
>
>
> Please review this WG document and let the WG know if you agree that it is
> ready for handing to the AD.
>
> If you have objections, please state your reasons why, and explain what it
> would take to address your concerns.
>
>
>
> Thanks
>
>
> Luigi & Joel
>
>
> ___
> lisp mailing listlisp@ietf.orghttps://www.ietf.org/mailman/listinfo/lisp
>
>
>
>
> ___
> lisp mailing listlisp@ietf.orghttps://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] Expiration impending:

[Albert Cabellos]

Hi all

I have reviewed the document and I am fine the way it is.

We have implemented LISP mobility clients in several platforms and the
main complexity comes from NAT Traversal and the many different corner
cases that a developer needs to take into account.

I think that the WG should focus on this
(https://datatracker.ietf.org/doc/draft-ermagan-lisp-nat-traversal/)
too when considering mobility.

Albert

On Tue, Apr 17, 2018 at 8:37 AM, Luigi Iannone  wrote:
> Folks,
>
> Dino is right.
> Please comment on the document.
>
> Thanks
>
> Luigi
>
>
> On 17 Apr 2018, at 00:25, Dino Farinacci  wrote:
>
> I can do an update before expiration but this would be a good time to
> receive comments from anyone in the working group.
>
> Thanks in advance,
> Dino
>
> Begin forwarded message:
>
> Resent-From: 
> From: IETF Secretariat 
> Date: April 16, 2018 at 7:42:11 AM EDT
> Resent-To: farina...@gmail.com, darle...@cisco.com, d...@1-4-5.net,
> ch...@logicalelegance.com
> To: 
> Cc: lisp-cha...@ietf.org, db3...@att.com
> Subject: Expiration impending: 
>
> The following draft will expire soon:
>
> Name: draft-ietf-lisp-mn
> Title:LISP Mobile Node
> State:I-D Exists
> Expires:  2018-04-26 (in 1 week, 2 days)
>
> ___
> 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] WG Last Call for draft-ietf-lisp-gpe-03

[Albert Cabellos]

Implemented in OOR

+1

On Tue, 10 Apr 2018 at 09:30, Albert López  wrote:

> +1
>
> Albert L.
>
> On 05/04/18 16:08, Luigi Iannone wrote:
>
> Hi All,
>
> During our last meeting, the authors of the LISP GPE document  [
> https://tools.ietf.org/html/draft-ietf-lisp-gpe-03]
> asked for Last Call. The room showed consensus and no objections were
> raised.
>
> This email starts the usual two weeks WG Last Call, to end April 20th,
> 2018.
>
> Please review this WG document and let the WG know if you agree that it is
> ready for handing to the AD.
> If you have objections, please state your reasons why, and explain what it
> would take to address your concerns.
>
> Thanks
>
> Luigi & Joel
>
>
> ___
> lisp mailing listlisp@ietf.orghttps://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] [Ila] Securing pull-based ID/LOC caches

[Albert Cabellos]

Hi Tom

Thank you very much for your feedback, please see inline:

On Fri, Mar 23, 2018 at 12:46 PM, Tom Herbert <t...@quantonium.net> wrote:

> On Thu, Mar 22, 2018 at 9:13 AM, Albert Cabellos
> <albert.cabel...@gmail.com> wrote:
> > Hi all
> >
> > I am attaching a short paper describing a solution for control-plane
> > denial-of-service & overflowing attacks against pull-based ID/LOC caches.
> > The solution is based on implementing a per-source rate-limiter at the
> xTR
> > using an efficient Count-Min Sketch structure.
> >
> Hi Albert,
>
> Thank you for forwarding the paper. It is an interesting read!
>
> I have a few comments:
>
> From the paper: "In LISP the mapping from the overlay namespaces can
> be done using two mechanisms."
>
> I believe a third mechanism is exists in secure redirects. This is
> akin to ICMP redirects where a network router informs a sender that
> there is a better path. This is sort of a hybrid of the pull and push
> models.
>

Agreed, as we point in the short paper alternative LISP deployment models
are possible [draft-rodrigueznatal-ila-lisp-00] if the assumptions
described in the paper do not hold.

>From the paper: "It is worth noting that this solution assumes that
> spoofing source addresses is not possible inside the LISP site". That
> is a big assumption and I'm not sure it will be generally true.
>
>
We consider it a reasonable assumption, particularly for data-center and 5G
scenarios.


> Even if if spoofing is enabled, trying to identify bad guys by source
> address is still precarious. Consider that there could be complex
> downstream networks of LISP that are possibly behind NAT, delegated
> prefixes, VMs sharing common server IP address, etc.
>
>
The paper focuses on source IP addresses but it can be trivially adapted to
identify users using any information in the packet headers or from the
network infrastructure.

You might also want to consider the possibility of a distributed
> denial of service attack where the attacker uses many system to attack
> a cache where no individual systems sends a high enough rate of
> packets to trip the rate limiting threshold. I imagine the code for an
> attack on cache is pretty trivial-- little more than a simple loop
> sending UDP packets to random destinations. This could very easily be
> hidden in some downloaded app.
>

The threshold determines what is and what is not an attacker, if they are
below T then this means that they are not overflowing the control-plane
channel. In other words, T is related to the maximum throughput of this
channel.

>
> From the paper: "Attackers generate (randomly) between 2 and 3 orders
> of magnitude more control-plane messages than legitimate users.
> Specifically, attackers generate a uniform random number in the range
> of 1k-10k, legitimate users a range in 1-10 and the threshold T is set
> to 1k"
>
> The job of an attacker is blend in so that their traffic is
> indistinguishable from users. If they know they know what the
> thresholds are that raise suspicion then they'll adjust their attack
> to avoid hitting the thresholds! In this case, for instance, they
> could try a DDOS to avoid detection.
>
>
In my view this is orthogonal. You pick T (the threshold) so that it
determines the maximum throughput of your control-plane channel. If they
are below T then you have enough resources to accommodate all control-plane
messages.

Caches also have other attack vectors. For instance, if an attacker
> knows they hash algorithm and the cache scheme, they might be able to
> launch and attack to prevent service to specific destinations by
> targeting the hash buckets of the destination. This sort of attack
> comes up a lot in traffic steering which is why all those schemes
> requiring randomizing the hash key and occasionally rekeying.
>

Yes, but LFU-A or ARC mechanisms require attackers to generate as much
traffic to unpopular destinations as the popular destinations are
receiving. If this happens in your network this roughly means that you have
more traffic from attackers than from legitimate users. Then what is the
'legitimate traffic'? Either you fix your network or you serve what your
users want.

We have seen over and over that traffic is a long-tail distribution, some
destinations are very popular while many other destinations are not
popular. The same applies to the pages accessed by a computer program, etc.
This is the underlying reason why caches are so prevalent in computer
science. With long-tail distributions they are very efficient in terms of
resource consumption.

>From the paper: "The main design rationale behind the proposed
> solution is to detect and push-back attackers by rate-limiting them in
> aggregating points

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

[Albert Cabellos]

Hi

I don't have a name suggestion either, but I do find it odd having a
> document with these 3 seemingly unrelated items (mobility seems to be the
> odd one out). So I would be in favour of proposal from Albert below.



I think that this another very good point, it is indeed strange and results
in a document without clear focus.

Kind regards

Albert

On Tue, Mar 20, 2018 at 2:58 PM, Reshad Rahman (rrahman) 
wrote:

> I don't have a name suggestion either, but I do find it odd having a
> document with these 3 seemingly unrelated items (mobility seems to be the
> odd one out). So I would be in favour of proposal from Albert below.
>
> Regards,
> Reshad.
>
> On 2018-03-19, 4:53 PM, "lisp on behalf of Dino Farinacci" <
> lisp-boun...@ietf.org on behalf of farina...@gmail.com> wrote:
>
> > 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 like to support an idea that Albert provided after
> the meeting today.
>
> He suggested to put the Mobility sections in an Appendix in RFC6830bis
> and put Deployment and Traceroute considerations in a document that now can
> be called “draft-ietf-lisp-oam”.
>
> Wonder how people would feel about that?
>
> 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

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

[Albert Cabellos]

Hi all

I just posted -12 with the changes suggested by Luigi

Albert

On Tue, Mar 6, 2018 at 9:29 AM, Luigi Iannone <g...@gigix.net> wrote:

> Hi Albert,
>
> thanks for submitting the updated document.
>
> I have have a few residual nits listed below. Fixed those we can move to
> LC IMO.
>
> Ciao
>
> L.
>
>
>
>LISP Nonce:  The LISP 'Nonce' field is a 24-bit value that is
>   randomly generated by an ITR when the N-bit is set to 1.  Nonce
>   generation algorithms are an implementation matter but are
>   required to generate different nonces when sending to different
>   destinations.
>
> [Luigi]
> As stated for -07: What is a destination? Should be different RLOCs, for
> clarity.
>
>
> The Clock Sweep mechanism is just about management should go in AOM.
>
>
> The following document are not Normative:
>
>  [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
>   "Randomness Requirements for Security", BCP 106 
> <https://tools.ietf.org/html/bcp106>, RFC 4086 
> <https://tools.ietf.org/html/rfc4086>,
>   DOI 10.17487/RFC4086, June 2005,
>   <https://www.rfc-editor.org/info/rfc4086>.
>
>
> [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
>   Support in IPv6", RFC 6275 
> <https://tools.ietf.org/html/rfc6275>, DOI 10.17487/RFC6275, July
>   2011, <https://www.rfc-editor.org/info/rfc6275>.
>
>
>
>
>
>
> On 5 Mar 2018, at 22:33, Albert Cabellos <albert.cabel...@gmail.com>
> wrote:
>
> Hi
>
> I'll post a new version without such sections shortly.
>
> I volunteer to help writing the OAM document.
>
> Albert
>
> On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci <farina...@gmail.com>
> wrote:
>
>> >> 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
>> Considerations), 18 (Traceroute Consideration) to a new OAM document
>> >>>
>> >>> The authors would like to have a better understanding of where this
>> text will go.
>> >>
>> >> Right, we concluded to not remove the valuable text.
>> >
>> > Nobody wants to lose valuable text.
>>
>> Glad you feel that way.
>>
>> >
>> >> A lot of time and thought went into writing it and we didn’t want to
>> lose it. There was no where that was agreed upon to put it.
>> >
>> > That is not accurate. There was clear indication to move it to a new
>> OAM document, without any change in the text.
>> > Purpose was to have just a different placeholder that make more sense.
>> > This is an half an hour task.
>>
>> But there was also concerns about slowing the process down. And the
>> co-authors (Albert and I) don’t think it should move from RFC6833.
>>
>> So there isn’t concensus. And I don’t believe it is even rough concensus.
>>
>> >
>> >>
>> >> So since we felt there was no concensus on Sections 16-18, we didn’t
>> make any change.
>> >
>> > Again not accurate, please spend half an hour to create the OAM
>> document.
>> > If you do not have time we can appoint other editors for the task.
>> Authorship will be anyway preserved.
>>
>>
>> Section 16 is “Mobility Considerations” that discusses various forms of
>> how EIDs can change RLOCs. And it sets up for different designs that are
>> already documented in various documents. But Mobility certainly shouldn’t
>> go in an OAM document.
>>
>> Section 17 discusses where xTRs (data-plane boxes) should reside in the
>> network. And sets up for a more detail discussion which is in the
>> Deployment RFC.
>>
>> Section 18 is “Traceroute Considerations”, this arguably can go into an
>> OAM document. But it would be 3 pages. And then one would argue there are
>> other OAM mechanisms spread across LISP documents that could go in an OAM
>> document.
>>
>> This will not take 1/2 hour.
>>
>> And I’m finding it hard to see the value in doing all this busy work. We
>> have already accomplished separating data-plane text from control-plane
>> text. We achieved that goal from the charter.
>>
>> Dino
>>
>>
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Albert Cabellos]

Hi

I'll post a new version without such sections shortly.

I volunteer to help writing the OAM document.

Albert

On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci  wrote:

> >> On 5 Mar 2018, at 19:06, Dino Farinacci  wrote:
> >>
> >>> Hi all
> >>>
> >>> This document should address all the comments except this one:
> >>>
> >>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
> Considerations), 18 (Traceroute Consideration) to a new OAM document
> >>>
> >>> The authors would like to have a better understanding of where this
> text will go.
> >>
> >> Right, we concluded to not remove the valuable text.
> >
> > Nobody wants to lose valuable text.
>
> Glad you feel that way.
>
> >
> >> A lot of time and thought went into writing it and we didn’t want to
> lose it. There was no where that was agreed upon to put it.
> >
> > That is not accurate. There was clear indication to move it to a new OAM
> document, without any change in the text.
> > Purpose was to have just a different placeholder that make more sense.
> > This is an half an hour task.
>
> But there was also concerns about slowing the process down. And the
> co-authors (Albert and I) don’t think it should move from RFC6833.
>
> So there isn’t concensus. And I don’t believe it is even rough concensus.
>
> >
> >>
> >> So since we felt there was no concensus on Sections 16-18, we didn’t
> make any change.
> >
> > Again not accurate, please spend half an hour to create the OAM document.
> > If you do not have time we can appoint other editors for the task.
> Authorship will be anyway preserved.
>
>
> Section 16 is “Mobility Considerations” that discusses various forms of
> how EIDs can change RLOCs. And it sets up for different designs that are
> already documented in various documents. But Mobility certainly shouldn’t
> go in an OAM document.
>
> Section 17 discusses where xTRs (data-plane boxes) should reside in the
> network. And sets up for a more detail discussion which is in the
> Deployment RFC.
>
> Section 18 is “Traceroute Considerations”, this arguably can go into an
> OAM document. But it would be 3 pages. And then one would argue there are
> other OAM mechanisms spread across LISP documents that could go in an OAM
> document.
>
> This will not take 1/2 hour.
>
> And I’m finding it hard to see the value in doing all this busy work. We
> have already accomplished separating data-plane text from control-plane
> text. We achieved that goal from the charter.
>
> Dino
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Albert Cabellos]

Hi all

This document should address all the comments except this one:

G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document


The authors would like to have a better understanding of where this text
will go.

If we adress this by today I can submit a new version (before the cut-off)
taking this comment into account.

Thanks!

Albert

On Mon, Mar 5, 2018 at 10:44 AM, Luigi Iannone <g...@gigix.net> wrote:

> Hi Albert, Dino,
>
> this version of the document doesn’t not yet completely respect the
> discussions of the last months.
>
> Do you plan another version before London?
>
> Thanks
>
> Luigi
>
>
> > On 5 Mar 2018, at 00:51, 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   : The Locator/ID Separation Protocol (LISP)
> >Authors : Dino Farinacci
> >  Vince Fuller
> >      Dave Meyer
> >  Darrel Lewis
> >  Albert Cabellos
> >   Filename: draft-ietf-lisp-rfc6830bis-10.txt
> >   Pages   : 50
> >   Date: 2018-03-04
> >
> > Abstract:
> >   This document describes the data-plane protocol for the Locator/ID
> >   Separation Protocol (LISP).  LISP defines two namespaces, End-point
> >   Identifiers (EIDs) that identify end-hosts and Routing Locators
> >   (RLOCs) that identify network attachment points.  With this, LISP
> >   effectively separates control from data, and allows routers to create
> >   overlay networks.  LISP-capable routers exchange encapsulated packets
> >   according to EID-to-RLOC mappings stored in a local map-cache.
> >
> >   LISP requires no change to either host protocol stacks or to underlay
> >   routers and offers Traffic Engineering, multihoming and mobility,
> >   among other features.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-10
> > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-10
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-10
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.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
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Albert Cabellos]

Hi all

Thanks for all the comments, from my understanding of this thread the
following list of items *seem* to have rough consensus (all except B -
change definitions for EID and RLOC).

Joel, Luigi->How should we proceed now?

Albert

---

A.- Remove definitions of PA and PI

C.- In section 5.3, change the description of the encap/decap operation
concerning how to deal with ECN and DSCP bits to (new text needs to be
validated by experts):

When doing ITR/PITR encapsulation:


o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case
of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.


o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.


o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy
the 2-bit 'ECN' field from the inner header to the outer header.
Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer
header to the new outer header.


When doing ETR/PETR decapsulation:


 o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the
case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field,
when the Time to Live value of the outer header is less than the Time to
Live value of the inner header.  Failing to perform this check can cause
the Time to Live of the inner header to increment across
encapsulation/decapsulation cycles.  This check is also performed when
doing initial encapsulation, when a packet comes to an ITR or PITR destined
for a LISP site.


o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.


o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. If the 'ECN' field contains
a congestion indication codepoint (the value is '11', the Congestion
Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the surviving inner header
that is used to forward the packet beyond the ETR.  These requirements
preserve CE indications when a packet that uses ECN traverses a LISP tunnel
and becomes marked with a CE indication due to congestion between the
tunnel endpoints.


Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate
after decapsulating, the net effect of this is that the new outer header
will carry the same Time to Live as the old outer header minus 1.


Copying the Time to Live (TTL) serves two purposes: first, it preserves the
distance the host intended the packet to travel; second, and more
importantly, it provides for suppression of looping packets in the event
there is a loop of concatenated tunnels due to misconfiguration.  See
Section 18.3 for TTL exception handling for traceroute packets.


D.- Simplify section ‘Router Locator Selection’ stating that the data-plane
MUST follow what´s stored in the map-cache (priorities and weights), the
remaining text should go to an OAM document.

E.- Rewrite Section “Routing Locator Reachability” considering the
following 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 probing

F.- Move Solicit-Map-Request to 6833bis

G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document


On Fri, Jan 26, 2018 at 8:20 PM, Dino Farinacci  wrote:

> Thanks for the detail review Padma. A new update to -09 is enclosed with a
> diff file. I will wait until next week to post.
>
> I have reflected all of your comments and most of Luigi’s comments. The
> only issues open are:
>
> (1) Section movement from RFC6830 to RFC6833.
>
> (2) If an OAM document is needed.
>
> Waiting for more working group concensus on this.
>
> > Dear Dino and Albert
> >
> > The doc reads well.
> > Please find thereafter some comments on the version- 09 you posted on
> the list
> >
> > Page 4
> > "Client-side:  Client-side is a term used in this document to indicate a
> connection initiation attempt by an EID."
> > PPE 1: Strictly speaking the EID is just an identifier and does not
> initiate anything. Suggest something like this.
> >
> > "Client-side:  Client-side is a term used in this document to indicate a
> connection 

[lisp] Confirm/Deny changes on draft 6830bis

[Albert Cabellos]

Hi all

As editor of 6830bis I´d like to confirm or deny the following changes
which I believe have support.

Please note that I have intentionally ignored minor/editorial changes to
help sync all the participants. I hope that the list below captures the
most relevant ones.

Also note that I don´t necessarily agree with all the changes listed below,
but that´s an opinion with a different hat.

WG: Please CONFIRM or DENY:

---

A.- Remove definitions of PA and PI

B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and
‘identifier of the underlay’ respectively.

C.- In section 5.3, change the description of the encap/decap operation
concerning how to deal with ECN and DSCP bits to (new text needs to be
validated by experts):

When doing ITR/PITR encapsulation:

o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case
of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.

o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy
the 2-bit 'ECN' field from the inner header to the outer header.
Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer
header to the new outer header.

When doing ETR/PETR decapsulation:

 o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the
case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field,
when the Time to Live value of the outer header is less than the Time to
Live value of the inner header.  Failing to perform this check can cause
the Time to Live of the inner header to increment across
encapsulation/decapsulation cycles.  This check is also performed when
doing initial encapsulation, when a packet comes to an ITR or PITR destined
for a LISP site.

o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. If the 'ECN' field contains
a congestion indication codepoint (the value is '11', the Congestion
Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the surviving inner header
that is used to forward the packet beyond the ETR.  These requirements
preserve CE indications when a packet that uses ECN traverses a LISP tunnel
and becomes marked with a CE indication due to congestion between the
tunnel endpoints.

Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate
after decapsulating, the net effect of this is that the new outer header
will carry the same Time to Live as the old outer header minus 1.

Copying the Time to Live (TTL) serves two purposes: first, it preserves the
distance the host intended the packet to travel; second, and more
importantly, it provides for suppression of looping packets in the event
there is a loop of concatenated tunnels due to misconfiguration.  See
Section 18.3 for TTL exception handling for traceroute packets.


D.- Simplify section ‘Router Locator Selection’ stating that the data-plane
MUST follow what´s stored in the map-cache (priorities and weights), the
remaining text should go to an OAM document.

E.- Rewrite Section “Routing Locator Reachability” considering the
following 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 probing



F.- Move Solicit-Map-Request to 6833bis

G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Albert Cabellos]

Hi


As far as I remember we didn´t agree on 3 documents, this does not
necessarily mean that it is a bad idea.


I still think that SMR should be on 6833bis, it is important to standardize
a control-plane that includes the capability of updating EID-to-RLOC
mappings.


Regarding sections Multicast, Mobility and Traceroute considerations they
could be easily moved to an OAM document, but it is quite complex to
properly contextualize such sections in a single standalone document. Do
they have value without the context of 6830bis? In my view they are better
in 6830bis.


I would like to hear other opinions from the list


Albert

On Mon, Jan 8, 2018 at 7:22 PM, Dino Farinacci  wrote:

> Do you think it is okay to capture the changes we have made and agreed
> upon so far so we can submit -08 and wait for other WG members to comment
> on this issue?
>
> What you are suggesting is a lot change that what was previously agreed
> upon. No one was really in favor of having a third document (your OAM
> reference below (3)).
>
> Also the chairs didn’t suggest any changes, it was Luigi (acting as a
> document shepherd). I am not sure the same comment came from Joel, either
> publicly or privately.
>
> Dino
>
> > On Jan 8, 2018, at 9:16 AM, Damien Saucez 
> wrote:
> >
> > Hello Dino, The List,
> >
> > That’s pretty cool to see activity around the document however I am not
> sure the proposed
> > changes are really addressing the structural problem of the document.
> >
> > The current document is a mix between data-plane, control-plane, and
> operation questions.
> >
> > The chairs proposition of re-balancing the text between 30bis, 33bis and
> an OAM documents
> > is great. It would allow people to go directly to the point they are
> interested in.
> >
> > 1. What goes on the wire: 30bis
> > 2. Signalling procedures: 33bis
> > 3. Implementation details, management, and troubleshooting: OAM.
> >
> > So it would mean that in 30bis it would just be all what is strictly
> needed to allow
> > inter-operability between xTRs, so at the end only packet format and how
> to understand
> > fields should be there. In this case, we can abstract the xTR as just a
> database that
> > stores mapping, how mapping are managed in this database is an
> implementation
> > question that is independent of the protocol itself.
> >
> > For 33bis, it would just be the format of signalling messages and how to
> interpret
> > them, when a signal is expected to be triggered.
> >
> > Finally, in OAM it would be how to implement and manage a LISP system
> that is
> > constituted of the LISP control-plane proposed in 33bis and the LISP
> data-plane in
> > 30bis.
> >
> > To say it clearly: remove from 30bis and 33bis all what is just the
> reflect of one
> > implementation. Normally these two document should have only what is
> strictly
> > necessary for people to implement (the way THEY want) a system that would
> > Inter-operate with the others.
> >
> > If we look at OpenLISP and its control-plane and the deployment of
> LISP-Lab
> > that we use in production daily, we can see that the data plane and
> control plane
> > have been implemented independently (and by different teams and even
> > companies) and what we can say is that a large fraction of the text in
> 60bis
> > has not been used at all for implementing the data-plane, while, on the
> contrary
> > we had to massively read/use text from 30bis to be able to implement the
> > control-plane. Finally, people that deployed LISP-Lab had to take content
> > from both 30bis and 33bis to be able to have a working environment. That
> > demonstrates that the separation is not done properly as normally people
> > in charge of deploying a network should not have to read the data-plane
> > specs, or people implementing a control-plane should not have to read
> > data-plane specifications.
> >
> > I think 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
> >
> >> On 4 Jan 2018, at 18:00, Dino Farinacci  wrote:
> >>
> >> Is the working group okay with me submitting these changes? This was
> the latest update from email before the year ended. I have made most of the
> changes that Luigi suggested or requested.
> >>
> >> 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

Re: [lisp] 6830bis Review

[Albert Cabellos]

Hi all

Please find my comments inline:


On Wed, Dec 27, 2017 at 5:13 AM, Dino Farinacci <farina...@gmail.com> wrote:

> 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 <albert.cabel...@gmail.com>
> wrote:
> >
> > Hi
> >
> > Thanks for the review, please find my comments inline.
> >
> > I have removed all the comments for which I **agree**:
> >
> > >
> > >   Provider-Assigned (PA) Addresses:   PA addresses are an address block
> > >  assigned to a site by each service provider to which a site
> > >  connects.  Typically, each block is a sub-block of a service
> > >  provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
> > >  is aggregated into the larger block before being advertised into
> > >  the global Internet.  Traditionally, IP multihoming has been
> > >  implemented by each multihomed site acquiring its own globally
> > >  visible prefix.  LISP uses only topologically assigned and
> > >  aggregatable address blocks for RLOCs, eliminating this
> > >  demonstrably non-scalable practice.
> > >
> > > Last sentence to be deleted is a relic of scalability discussion.
> > >
> > >
> >
> > Agreed. I suggest deleting entirely the definitions for both PA and PI,
> they are not used throughout the document.
>
> 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.
>
> I don’t know why any of you would think differently.
>

We are solving this issue and many others. But the point of the document is
specifying a data-plane, not the benefits of this data-plane.


>
> >
> > [snip]
> > >
> > >
> > >   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
> > >  IPv6) value used in the source and destination address fields of
> > >  the first (most inner) LISP header of a packet.  The host obtains
> > >  a destination EID the same way it obtains a destination address
> > >  today, for example, through a Domain Name System (DNS) [RFC1034]
> > >  lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
> > >  The source EID is obtained via existing mechanisms used to set a
> > >  host's "local" IP address.  An EID used on the public Internet
> > >  must have the same properties as any other IP address used in that
> > >  manner; this means, among other things, that it must be globally
> > >  unique.  An EID is allocated to a host from an EID-Prefix block
> > >  associated with the site where the host is located.  An EID can be
> > >  used by a host to refer to other hosts.  Note that EID blocks MAY
> > >  be assigned in a hierarchical manner, independent of the network
> > >  topology, to facilitate scaling of the mapping database.  In
> > >  addition, an EID block assigned to a site may have site-local
> > >  structure (subnetting) for routing within the site; this structure
> > >  is not visible to the global routing system.  In theory, the bit
> > >  string that represents an EID for one device can represent an RLOC
> > >  for a different device.  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.
> > >
> > >
> > > Is the above sentence really necessary?
> > >
> >
> > Agreed, why not simplify the definitions. They are written from the
> ‘Internet scalability mindset’, why not say that an EID is an address of
> the overlay and an RLOC an address of the overlay. This change may require
> further changes on the document so I am not 100% sure if this is a good
> idea.
>
> I have planned to remove the sentence.
>

What do you think about defining an EID as an identifier of the overlay and
an RLOC as an identifier of the underlay? (Probably this needs to be
reworded, but you get my point).

In my view this definition is broader and accounts for many of the LCAF
uses.


>
>
>
> >
> > >
> > > The description of the encap/decap operation lacks of clarity
> concerning how to deal with
> > > ECN bits and DSCP .
> > >
> > > 1. I think that the text should make explicitly the difference between
> DSCP and ECN fields.
> > >
> > > 2. How to deal wit

Re: [lisp] 6830bis Review

[Albert Cabellos]

Hi

Thanks for the review, please find my comments inline.

I have removed all the comments for which I **agree**:

>
>   Provider-Assigned (PA) Addresses:   PA addresses are an address block
>  assigned to a site by each service provider to which a site
>  connects.  Typically, each block is a sub-block of a service
>  provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
>  is aggregated into the larger block before being advertised into
>  the global Internet.  Traditionally, IP multihoming has been
>  implemented by each multihomed site acquiring its own globally
>  visible prefix.  LISP uses only topologically assigned and
>  aggregatable address blocks for RLOCs, eliminating this
>  demonstrably non-scalable practice.
>
> Last sentence to be deleted is a relic of scalability discussion.
>
>

Agreed. I suggest deleting entirely the definitions for both PA and PI,
they are not used throughout the document.

[snip]
>
>
>   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
>  IPv6) value used in the source and destination address fields of
>  the first (most inner) LISP header of a packet.  The host obtains
>  a destination EID the same way it obtains a destination address
>  today, for example, through a Domain Name System (DNS) [RFC1034]
>  lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
>  The source EID is obtained via existing mechanisms used to set a
>  host's "local" IP address.  An EID used on the public Internet
>  must have the same properties as any other IP address used in that
>  manner; this means, among other things, that it must be globally
>  unique.  An EID is allocated to a host from an EID-Prefix block
>  associated with the site where the host is located.  An EID can be
>  used by a host to refer to other hosts.  Note that EID blocks MAY
>  be assigned in a hierarchical manner, independent of the network
>  topology, to facilitate scaling of the mapping database.  In
>  addition, an EID block assigned to a site may have site-local
>  structure (subnetting) for routing within the site; this structure
>  is not visible to the global routing system.  In theory, the bit
>  string that represents an EID for one device can represent an RLOC
>  for a different device.  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.
>
>
> Is the above sentence really necessary?
>

Agreed, why not simplify the definitions. They are written from the
‘Internet scalability mindset’, why not say that an EID is an address of
the overlay and an RLOC an address of the overlay. This change may require
further changes on the document so I am not 100% sure if this is a good
idea.

[snip]
>
>   Re-encapsulating Tunneling in RTRs:   Re-encapsulating Tunneling
>
> RTR have never been defined.


Agree, they are defined in LISP-TE, not sure about the rules here. They are
used in section 17.

[snip]
>
>   Recursive Tunneling:   Recursive Tunneling occurs when a packet has
>  more than one LISP IP header.  Additional layers of tunneling MAY
>  be employed to implement Traffic Engineering or other re-routing
>  as needed.  When this is done, an additional "outer" LISP header
>  is added, and the original RLOCs are preserved in the "inner"
>  header.
>
> Do not think the following sentence is really necessary.
>

It is an easy way to explain that tunnels can be nested, may be obvious for
us but not for some readers. In any case the term ‘recursive tunneling’ is
used several times throughout the document. I don´t have a strong opinion
but I´d say leave it as it is.

>
>   o  EIDs are typically IP addresses assigned to hosts.
>
>   o  Other types of EID are supported by LISP, see [RFC8060] for
>  further information.
>
> I would put the last two bullets in the definition of EID. It simplifies
the story here.
>
>

I suggest to leave them here, I don´t think that readers start from the
‘Definition of terms’, these are relevant concepts to understand LISP.

>
> The description of the encap/decap operation lacks of clarity concerning
how to deal with
> ECN bits and DSCP .
>
> 1. I think that the text should make explicitly the difference between
DSCP and ECN fields.
>
> 2. How to deal with ECN should be part of the description of the
 encap/decap not a paragraph apart.
>This basically means that half of the last paragraph should be a
bullet of the ITR/PITR encapsulation
>and the other half  in the ETR/PETR operation.


Agreed, what about this (please comment):

   When doing ITR/PITR encapsulation:

o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the
case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
o  The outer-header 'Differentiated Services Code Point' (DSCP) field
(or the 'Traffic Class' field, 

Re: [lisp] RFC6830bis and multiprotocol support

[Albert Cabellos]

Hi all

Support proposed 6830bis extension.

This is indeed implmemented in OOR.

Albert

On Thu, Nov 30, 2017 at 9:47 AM, Albert López  wrote:

> +1
>
> I also support extending RFC 6830bis as suggested. We have an initial
> implementation of LISP-GPE in OOR and we think this extension could be
> really useful.
>
> Albert López
>
>
>
> El 30/11/17 a les 07:32, Florin Coras ha escrit:
>
> +1
>
> The LISP implementation in FD.io VPP makes use of it to distinguish
> between Ethernet, IP and NSH payloads.
>
> Florin
>
> On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) 
> wrote:
>
> I’m strongly supportive of this proposal as it completes 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) 
> wrote:
>
> sounds good.
>
> Fabio
>
> On 11/29/17 3:13 PM, Dino Farinacci wrote:
>
> 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  wrote:
>
>
> On 11/29/17 3:05 PM, Dino Farinacci wrote:
>
> How about this wording Fabio:
>
>
> P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is
> used for the Next Protocol field. When the N-bit is also set with the
> P-bit, the Nonce field is the middle 16 bits. When the V bit is also set
> with the P-bit, the Version field is the middle 16 bits. Details on Next
> Protocol field usage are described in [draft-lewis-lisp-gpe].
>
>
> Comments?
>
> much better.
>
>
> Thanks,
>
> Fabio
>
>
> Dino
>
>
> On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:
>
>
> Definition of the P bit will look like:
>
>
>P: The P-bit is the Next Protocol bit. When this bit is set to
>
>   1, Nonce length, when used, is limited to 16 bits and the lenght
>
>   of the Source and Destination Map-Version fields, when used, is
> limited
>
>   to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
>
>   The P-bit is set to 1 to indicate 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:
>
> 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 Version
> field the middle 16-bits. So V and P can be set at the same as well as N
> and P.
>
>
> Dino
>
>
> Good point, shortening versions to 8 bits...
>
>
> Seems fine to me.
>
>
>
> Fabio
>
>
>
>
>
> ___
>
> 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 listlisp@ietf.orghttps://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] Current state of anycast IP-addresses in the LISP Beta Network?

[Albert Cabellos]

Hi Renne

Complementing what Albert López said, anycast at EID level for PxTRs is up
and running.

Best regards

Albert

On Mon, Oct 16, 2017 at 10:45 AM, Albert López  wrote:

> Dear Renne,
>
> LISP Beta Network is not using anycast addresses for MS/MR or PxTRs.
>
> On the other hand, not all the nodes of Beta Network have IPv6
> connectivity. You can find the current status of these nodes here
> .
>
> Best regards
>
> Albert
>
> El 12/10/17 a les 15:33, Rene 'Renne' Bartsch, B.Sc. Informatics ha escrit:
>
> Hi,
>
> does the LISP Beta Network currently use anycast IP-adresses (MS/MR,
> PxTRs)?
>
>
> Are the MS/MR, PxTRs reachable via IPv6 (e.g. IPv6-in-IPv6) via LISP?
>
>
> Regards,
>
> Renne
>
>
> ___
> 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] Call for WG Adoption of document draft-farinacci-lisp-predictive-rlocs-02.txt

[Albert Cabellos]

+1

Albert

On Fri, May 19, 2017 at 3:47 PM, Dino Farinacci  wrote:

> 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 the two weeks call for WG adoption.
> > The call ends on  June 2nd 2017.
> >
> > Please respond to the LISP mailing list with any statements of approval
> or disapproval.
> >
> > Recall that:
> >
> > - This is not WG Last Call. The document is not final, and the WG is
> expected to
> >   modify the document’s content until there is WG consensus that the
> content is solid.
> >   Therefore, please don’t oppose adoption just because you want to see
> changes to its content.
> >
> > - If you have objections to adoption of the document, please state your
> reasons why,
> >   and explain what it would take to address your concerns.
> >
> > - If you have issues with the content, by all means raise those issues
> and we can
> >   begin a dialog about how best to address them.
> >
> >
> > Luigi and Joel
> > ___
> > 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] DoS attacks to the Map-Cache

[Albert Cabellos]

(follow-up on the mic discussion at the LISP WG)

Here you can find a paper modeling, evaluating and discussing such aspect

https://arxiv.org/pdf/1312.1378.pdf

Albert
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Way forward on 6830bis

[Albert Cabellos]

+1 to this

Albert

On Thu, Nov 5, 2015 at 11:12 PM, Florin Coras  wrote:
> Definitely agree with this as well.
>
> As Damien mentioned, RFC6830 convolutes control-plane API definition and 
> semantics with data-plane operation. While I believe there should be a 
> section treating tunnel router interaction with the mapping-system in 
> RFC6830, the control-plane API definition (i.e., syntax and semantic of 
> messages exchanged by tunnel routers with the mapping-system), should be 
> moved to a separate document.
>
> Florin
>
>> On Nov 5, 2015, at 3:42 AM, Dino Farinacci  wrote:
>>
>> I certainly agree with your conclusions Fabio.
>>
>> Dino
>>
>>> On Nov 4, 2015, at 6:13 PM, Fabio Maino  wrote:
>>>
>>> On 11/5/15 11:06 AM, Damien Saucez wrote:
 On 05 Nov 2015, at 10:48, Dino Farinacci  wrote:

> On 05 Nov 2015, at 10:33, Dino Farinacci  wrote:
 Hello,

 By seeing Alberts presentation on SFC today I was just thinking that 
 we could
 split 6830 in two documents.

 One document to present the data-plane (mostly Sec 5).

 One document to present the control-plane (mostly Sec 6).

 As Albert said the mapping system is generic (with LCAF).  Therefore 
 it would
 make it more logical (to me at least) to have a document to strictly 
 talk about
 the mapping system and it would increase the appeal of the mapping 
 system by
 not requiring people to care about the LISP encapsulation if they only 
 need the
 mapping system function.
>>> The mapping system is in a separate document and spread across alt, 
>>> ddt, and ms specs. The control-plane text in RFC6830 is defining an API 
>>> to the mapping system. And I think you want it all in one place for 
>>> completeness.
>>>
>> When  I was talking about mapping system, I was talking about the
>> “API” (Map-Request, Map-Reply, Map-Register… ).
>>
>> I understand that it is not straightforward to make it in a nice way, but
>> the as LISP is about decoupling control-plane and data-plane it would
>> make sense to also decouple control and data-plane definition.
>>
>> Imagine you want someone to only implement the control-plane, how
>> does he know what to implement exactly to be fully compliant?
> This is clearly stated in RFC6830. That is, you can send a Map-Request 
> for any reason. It doesn’t have to be invoked by arrival of a packet on 
> an ITR/RTR/PITR. Tools like lig and rig are examples of this.
>

 Of course for someone who knows LISP it is trivial that it is separated.  
 The
 issue is how to move forward and ensure that LISP control plane is not 
 bound at
 all to a particular data-plane.  Actually, since the beginning we say LISP 
 is
 map-and-encap so it means two components mapping and encapsulation, that 
 seems
 thus very logical to me to have to documents, one for "mapping", one for
 “encapsulation".

 At a first glance it could look like just being marketing but actually 
 splitting
 would allow both planes to be developed (and updated) in parallel.
>>>
>>>
>>> Damien,
>>> I think this could be a good idea. Too many people still associate LISP 
>>> mostly with the encap (and it looks like too many don't read past the title 
>>> of the RFC... :-(
>>>
>>> We should also do a better work of explaining that LISP CP can be used as 
>>> generic mapping service for overlays (not only for on-demand LISP tunnel 
>>> provisioning).
>>>
>>> In retrospective we should have presented the LISP/NSH draft in SFC as 
>>> well.There might be more SFC use cases that can be addressed by the LISP 
>>> CP. It'd be helpful to have the people in SFC give a thought to the concept 
>>> of map assisted overlays.
>>>
>>> Fabio
>>>
>>>

 Damien Saucez

> Dino
>
>> Damien Saucez
>>
>>> Dino
>>>
 Cheers,

 Damien Saucez

 On 27 Oct 2015, at 01:25, Joel M. Halpern  wrote:

> It seemed to us that there was likely some confusiona bout how we 
> expect to handle the revision of RCC 6830.  The following is what we 
> currently expect.
>
> Once we have a new charter approved, the chairs will appoint an 
> editor for the revision of rfc6830.  That may be one of the existing 
> authors, or a new person.  We will ask for volunteers.
>
> Once we have an author, they will submit a starting ID called 
> draft-ietf-lisp-rfc6830bis-00 which will be identical in content to 
> the existing RFC.  That may require assistance from the RFC Editor to 
> ensure that we get all the changes they made during final 

Re: [lisp] Draft of new Proposed Charter

[Albert Cabellos]

Hi Luigi, Joel

Thanks for the draft, I think it describes very relevant action items for LISP.

I would also suggest exploring a flexible data-modeling language as a
complement to LCAF for LISP control. LCAF is too rigid and it lacks of
design guidelines to define new ones. A flexible language with a clear
syntax would ease deployment of new use-cases both at the data and
control plane. Maybe this could be done as experimental (not
standard).

Albert


On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino  wrote:
>
> Joel, Luigi,
> thanks for taking a stab at this one.
>
> I think it covers the relevant aspects that I would like to see the WG to 
> focus on.
>
> As discussed in the use case thread, I would suggest that the draft should 
> mention a very small set of use cases that we can use to drive the design 
> decisions. I think that we can possibly cover all of the protocol aspects you 
> describe if we take the following two use cases:
> 1) LISP-based programmable L2/L3 VPNs with extensions to support the 
> following services:
> - encryption
> - programmatic northbound access to the mapping and to xTR configuration
> - SFC/NFV
> - VPN termination on mobile nodes
> 2) LISP-based programmable L2/L3 VPNs for DC applications
>
> I think these two will give a good scope to the WG work and, without 
> resorting to more exotic use cases, reinforce the focus on the use of LISP as 
> an overlay technology.
>
> Thanks,
> Fabio
>
>
>
>
> On 10/13/15 1:30 PM, Luigi Iannone wrote:
>>
>> Folks,
>>
>> in the past weeks (and months) there was a fruitful discussion that took 
>> place on the mailing list (and also in Prague) concerning
>> the new charter to be adopted by our WG. Thanks for this effort.
>>
>> Beside this discussion we had proposals from WG members as well as 
>> discussion with our AD about what is practical and reasonable.
>> Hereafter you can find the result: a draft of the new proposed charter.
>>
>> This does not mean that discussion is over, rather that we reached a first 
>> consistent milestone for further discussion.
>> Discussion ideally culminating in our meeting in Japan.
>>
>> So please have look and send your thoughts and feedback to the mailing list.
>>
>> Joel and Luigi
>>
>> %—%
>> The LISP WG has completed the first set of Experimental RFCs
>> describing the Locator/ID Separation Protocol (LISP). LISP supports
>> a routing architecture which decouples the routing locators and
>> identifiers, thus allowing for efficient 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. The scope of the LISP
>>   technology is recognized to range from programmable overlays,
>> at Layer 2 as well as at Layer 3, including NAT traversal, and
>> supporting mobility as a general feature, independently of whether
>> it is a mobile user or a migrating VM, hence being applicable in both
>> Data Centers and public Internet environments.
>>
>> The LISP WG is chartered to continue work on the LISP base protocol
>> with the main objective to develop a standard solution based on the
>> completed Experimental RFCs and the experience gained from early
>> deployments.
>> This work will include reviewing the existing set of Experimental RFCs
>> and doing the necessary enhancements to support a base set of
>> standards track RFCs. The group will review the current set of Working
>> Group documents to identify potential standards-track documents and
>> do the necessary enhancements to support standards-track. It is
>> recognized that some of the work will continue on the experimental track,
>> though the group is encouraged to move the documents to standards
>> track in support of network use, whereas the work previously was
>> scoped to research studies.
>>
>> Beside this main focus, the LISP WG may work on the following items:
>>
>> •   NAT-Traversal
>> •   Mobility
>> •   Data-Plane Encryption
>> •   Multicast: Support for overlay multicast by means of replication
>>  as well as interfacing with existing underlay multicast support.
>> •   YANG Data models for management of LISP.
>> •   Multi-protocol support: Specifying the required extensions to support
>>  multi-protocol encapsulation (e.g.,   L2 or NSH – Network Service
>>  Headers). Rather than developing new encapsulations, the work will
>>  aim at using existing well-established encapsulations or emerging
>>  from other Working Groups such as  NVO3 and SFC.
>> •   Alternative Mapping System Design: When extending LISP to support
>>  new protocols,it may be also necessary to develop the related 
>> mapping
>>  function extensions to operate LISP map-assisted  networks (which
>>   

Re: [lisp] Draft of new Proposed Charter

[Albert Cabellos]

Hi Luigi

Please see my comments inline:

On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone  wrote:

[snip]

> Having design guidelines does not forcedly mean having a programmatic 
> language approach. Right?
>
> In your opinion  could well defined guidelines (not language) be added to the 
> current LCAF document?

I am unsure if we can do this without ending up reproducing some sort
of language, we´ll start by defining scalar data-types, then complex
data-types (combinations of scalars), then data-structures, then
encoding mechanisms for each scalar and each data-structure and so on.

This could be as simple as defining an encoding mechanisms for YANG
(XMLBIN with some sort of compression). I am not stating that we
should go this precise way, what I am stating is that LCAF is rigid
and, if a new use-case is not defined as an LCAF, it can´t be deployed
in a standard way. A language could solve this issue and make the LISP
control plane truly flexible.

>
>> to define new ones. A flexible language with a clear
>> syntax would ease deployment of new use-cases both at the data and
>> control plane.
>
> How much relevant and with what priority is this for the WG? ( _NOTE_ this 
> question is for the whole WG not just for Albert…)
>

me too :)

Albert

>> Maybe this could be done as experimental (not
>> standard).
>
> _if_ the WG decides to take on this work it would very reasonable to go for 
> experimental.
>
> ciao
>
> L.
>
>
>>
>> Albert
>>
>>
>> On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino  wrote:
>>>
>>> Joel, Luigi,
>>> thanks for taking a stab at this one.
>>>
>>> I think it covers the relevant aspects that I would like to see the WG to 
>>> focus on.
>>>
>>> As discussed in the use case thread, I would suggest that the draft should 
>>> mention a very small set of use cases that we can use to drive the design 
>>> decisions. I think that we can possibly cover all of the protocol aspects 
>>> you describe if we take the following two use cases:
>>> 1) LISP-based programmable L2/L3 VPNs with extensions to support the 
>>> following services:
>>>- encryption
>>>- programmatic northbound access to the mapping and to xTR configuration
>>>- SFC/NFV
>>>- VPN termination on mobile nodes
>>> 2) LISP-based programmable L2/L3 VPNs for DC applications
>>>
>>> I think these two will give a good scope to the WG work and, without 
>>> resorting to more exotic use cases, reinforce the focus on the use of LISP 
>>> as an overlay technology.
>>>
>>> Thanks,
>>> Fabio
>>>
>>>
>>>
>>>
>>> On 10/13/15 1:30 PM, Luigi Iannone wrote:

 Folks,

 in the past weeks (and months) there was a fruitful discussion that took 
 place on the mailing list (and also in Prague) concerning
 the new charter to be adopted by our WG. Thanks for this effort.

 Beside this discussion we had proposals from WG members as well as 
 discussion with our AD about what is practical and reasonable.
 Hereafter you can find the result: a draft of the new proposed charter.

 This does not mean that discussion is over, rather that we reached a first 
 consistent milestone for further discussion.
 Discussion ideally culminating in our meeting in Japan.

 So please have look and send your thoughts and feedback to the mailing 
 list.

 Joel and Luigi

 %—%
 The LISP WG has completed the first set of Experimental RFCs
 describing the Locator/ID Separation Protocol (LISP). LISP supports
 a routing architecture which decouples the routing locators and
 identifiers, thus allowing for efficient 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. The scope of the LISP
  technology is recognized to range from programmable overlays,
 at Layer 2 as well as at Layer 3, including NAT traversal, and
 supporting mobility as a general feature, independently of whether
 it is a mobile user or a migrating VM, hence being applicable in both
 Data Centers and public Internet environments.

 The LISP WG is chartered to continue work on the LISP base protocol
 with the main objective to develop a standard solution based on the
 completed Experimental RFCs and the experience gained from early
 deployments.
 This work will include reviewing the existing set of Experimental RFCs
 and doing the necessary enhancements to support a base set of
 standards track RFCs. The group will review the current set of Working
 Group documents to identify potential standards-track documents and
 do the necessary enhancements to support standards-track. It is
 recognized that some of the work will continue on the 

Re: [lisp] I-D Action: draft-ietf-lisp-introduction-13.txt

[Albert Cabellos]

Hi Alia

Thanks for the rewording, I agree that your suggeted text reads better.

We´ll incorporate this text along with further comments (if any) in a
revised version of the draft.

Regards

Albert

On Tue, Apr 14, 2015 at 9:04 PM, Alia Atlas akat...@gmail.com wrote:

 Hi Luigi,

 In Sec 3.1, as part of the Locator/Identifier Split, it says:

 Locator/Identifier split: By decoupling the overloaded semantics
   of the current IP addresses the Internet core can be assigned
   identity meaningful addresses and hence, can use aggregation to
   scale.  Devices are assigned with relatively opaque topologically
   meaningful addresses that are independent of their topological
   location.
 

 This still doesn't make sense!

 Locator/Identifier split:  Decoupling the overloaded semantics of current
 IP addresses allows devices to have identity-based addresses that are
 separate from topologically-meaningful addresses.  By allowing only the
 topologically-meaningful addresses to be exposed to the Internet core,
 those
 topologically-meaningful addresses can be aggregated to support substantial
 scaling.  Individual devices are assigned identity-based addresses that are
 not used for forwarding in the Internet core.

 is probably a lot closer to what you are trying to say - but please figure
 out
 what your points are and reread the text to make sure that it parses.

 This was in my comment and not the Discuss, so I am clearing that.

 Regards,
 Alia

 On Tue, Apr 14, 2015 at 6:02 AM, Luigi Iannone g...@gigix.net wrote:

 Hi,

 Did you get a chance to have a look to the latest version of this
 document to consider clearing the open discuss?

 May be to be added to the next tele chat agenda?

 ciao

 Luigi


 On 02 Apr 2015, at 21:56, Luigi Iannone g...@gigix.net wrote:

 Hi All,

 authors submitted a new version of the LISP introduction document
 addressing all of the discuss and comments previously raised.

 Please let us know if there is any residual issue.

 ciao

 Luigi


 Begin forwarded message:

 *From: *internet-dra...@ietf.org
 *To: *i-d-annou...@ietf.org
 *Subject: **I-D Action: draft-ietf-lisp-introduction-13.txt*
 *Date: *2 Apr 2015 14:27:11 CEST
 *Cc: *lisp@ietf.org
 *Reply-To: *internet-dra...@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 Working
 Group of the IETF.

Title   : An Architectural Introduction to the Locator/ID
 Separation Protocol (LISP)
Authors : Albert Cabellos
  Damien Saucez
 Filename: draft-ietf-lisp-introduction-13.txt
 Pages   : 27
 Date: 2015-04-02

 Abstract:
   This document describes the architecture of the Locator/ID Separation
   Protocol (LISP), making it easier to read the rest of the LISP
   specifications and providing a basis for discussion about the details
   of the LISP protocols.  This document is used for introductory
   purposes, more details can be found in RFC6830, the protocol
   specification.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-lisp-introduction-13

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-13


 Please note that it may take a couple of minutes from the time of
 submission
 until the htmlized version and diff are available at tools.ietf.org.

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.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] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT)

[Albert Cabellos]

Hi

Thanks for your comment, I agree with you, in some cases (e.g., NERD) LISP
can operate as a push architecture. We used the term pull arcihtecture to
introduce the use of RLOC probing, please let me know if the following
paragraph clarifies the point that you rised:

In most cases LISP operates with a pull-based Mapping System (e.g., DDT),
this results in an edge to edge pull architecture. In such scenario the
network state is stored in the control-plane while the data-plane pulls it
on demand.  This has consequences concerning the propagation of xTRs
reachability/liveness information since pull architectures require explicit
mechanisms to propagate this information.  As a result LISP defines a set
of mechanisms to inform ITRs and PITRS about the reachability of the cached
RLOCs:

Albert


On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear l...@cisco.com wrote:

 Hi,

 I'm sorry I didn't catch this earlier (attention elsewhere).

 On 3/3/15 11:09 PM, Adrian Farrel wrote:
  --
  DISCUSS:
  --
 
  Thank you for this document. It is really helpful to have a clear
  introduction to LISP, and I appreciate the hard work that has gone into
  producing this text.
 
  I have a small Discuss that is easily fixed. The essence is that you
  should limit this document to a description of LISP and not try to use
  it to bash other solutions.
 
  In Section 4.2
 
 On the contrary BGP is a
 push architecture, where the required network state is pushed by
 means of BGP UPDATE messages to BGP speakers.
 
  You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode
  protocol.
 
  (I won't say to you that LISP is push mode because a Map-Reply pushes
  the mapping information from the map server to the client :-)
 
  So, my advice is to describe LISP in this document and to not make
  comments about other systems. It isn't a beauty contest and it isn't
  wise to try to say my system is better/different from yours.
 
  The solution is to just remove this sentence.
 
  Similarly in 7.1
 
 BGP is the standard protocol to implement inter-domain routing.  With
 BGP, routing information are propagated along the network and each
 autonomous system can implement its own routing policy that will
 influence the way routing information are propagated.  The direct
 consequence is that an autonomous system cannot precisely control the
 way the traffic will enter the network.
 
 As opposed to BGP, a LISP site can strictly impose via which ETRs the
 traffic must enter the the LISP site network even though the path
 followed to reach the ETR is not under the control of the LISP site.
 
  Let's not get into the BGP this, BGP that debate. Just remove the
  first paragraph and the first four words of the second paragraph. That
  way you avoid all contention and write a document about LISP.


 I would go further.  Whether LISP is a pull- or a push architecture (or
 something else) is entirely a characteristic of the mapping system
 used.  The one in common use today is indeed a pull architecture.  The
 text discussing push/pull, therefore, should be addressed to the mapping
 system.

 Eliot



 ___
 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] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT)

[Albert Cabellos]

Hi

Thank you very much for your comments, please find below how we plan to
address them:

On Wed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins 
spencerdawkins.i...@gmail.com wrote:

 Spencer Dawkins has entered the following ballot position for
 draft-ietf-lisp-introduction-12: Yes

 When responding, please keep the subject line intact and reply to all
 email addresses included in the To and CC lines. (Feel free to cut this
 introductory paragraph, however.)


 Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
 for more information about IESG DISCUSS and COMMENT positions.


 The document, along with other ballot positions, can be found here:
 http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/



 --
 COMMENT:
 --

 I'm a Yes because this draft is helpful to the largely uninitiated (that
 would include me), but I was consistently encountering questions that
 Adrian's Discuss and Comments answered, so I'd encourage you to work
 through his Comments, as well as his Discuss.

 Beyond that:

 In this text:

 3.3.1.  LISP Encapsulation

ITRs encapsulate data packets towards ETRs.  LISP data packets are
encapsulated using UDP (port 4341), the source port is usually
selected by the ITR using a 5-tuple hash of the inner header (so to
be consistent in case of multi-path solutions such as ECMP [RFC2992])
and ignored on reception.

 would you ever use virtual xTRs with the same outermost IP addresses?
 If not, fine, but if so, would you need to use different destination
 ports to disambiguate them? Or does the Instance ID provide enough
 isolation to meet this need?

 I ask because adding virtual hosts to HTTP was a drag, so best for me to
 ask early!


Indeed and as you point out InstanceID should provide enough isolation.
Please let me know if the following sentence (section 4.1) clarifies your
point:

The Map-Cache is indexed by (Instance ID, EID-prefix) and
   contains basically the set of RLOCs with the associated traffic
   engineering policies (priorities and weights).


Further in the same paragraph, in this text:

A particularity of LISP is that UDP
packets should include a zero checksum [RFC6935] [RFC6936] that it is
not verified in reception, LISP also supports non-zero checksums that
may be verified.  This decision was made because the typical
transport protocols used by the applications already include a
checksum, by neglecting the additional UDP encapsulation checksum
xTRs can forward packets more efficiently.

 I'm wobbling between should include a zero checksum and also supports
 non-zero checksums. Is that text saying something like this?

LISP data packets are often encapsulated in UDP packets that
include a zero checksum [RFC6935] [RFC6936] that is not verified
when it is received, because LISP data packets typically include
an inner transport protocol header with a non-zero checksum. By
omitting the additional outer UDP encapsulation checksum, xTRs
can forward packets more efficiently. If LISP data packets are
encapsulated in UDP packets with non-zero checksums, the outer
UDP checksums are verified when the UDP packets are received, as
part of normal UDP processing.


This is correct, I'll update the paragraph as you suggest, thanks!

Albert


 ___
 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-introduction-11.txt

[Albert Cabellos]

Updated following Radia Perlman's review.

Albert

On Tue, Feb 10, 2015 at 12:39 AM, 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 Working
 Group of the IETF.

 Title   : An Architectural Introduction to the Locator/ID
 Separation Protocol (LISP)
 Authors : Albert Cabellos
   Damien Saucez
 Filename: draft-ietf-lisp-introduction-11.txt
 Pages   : 27
 Date: 2015-02-09

 Abstract:
This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details
of the LISP protocols.  This document is used for introductory
purposes, more details can be found in RFC6830, the protocol
specification.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-lisp-introduction-11

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-11


 Please note that it may take a couple of minutes from the time of
 submission
 until the htmlized version and diff are available at tools.ietf.org.

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.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

[lisp] Fwd: I-D Action: draft-ietf-lisp-introduction-10.txt

[Albert Cabellos]

Hi all

I´ve just posted draft-ietf-lisp-introduction-10.txt following AD's
comments.

Albert

-- Forwarded message --
From: internet-dra...@ietf.org
Date: Wed, Jan 21, 2015 at 7:21 PM
Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-10.txt
To: i-d-annou...@ietf.org
Cc: 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 Working
Group of the IETF.

Title   : An Architectural Introduction to the Locator/ID
Separation Protocol (LISP)
Authors : Albert Cabellos
  Damien Saucez
Filename: draft-ietf-lisp-introduction-10.txt
Pages   : 26
Date: 2015-01-21

Abstract:
   This document describes the architecture of the Locator/ID Separation
   Protocol (LISP), making it easier to read the rest of the LISP
   specifications and providing a basis for discussion about the details
   of the LISP protocols.  This document is used for introductory
   purposes, more details can be found in RFC6830, the protocol
   specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-introduction-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.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] AD Evaluation: draft-ietf-lisp-introduction

[Albert Cabellos]

Hi

Thanks, please see inline my replies (removed text for which we all agree):


 [snip]



 
  * The discussion of SMR should contain a reference to 6830 or a
  brief discussion of how the SMR is used.
 
 
  Could you please elaborate further this comment?
 
  Solicit-Map-Request (SMR):  SMR is an explicit mechanism to update
  mapping information.  In particular a special type of Map-Request can
  be sent on demand by ETRs to request refreshing a mapping. Upon
  reception of a SMR message, the ITR must refresh the bindings by
  sending a Map-Request to the Mapping System.

 There are more interesting conditions/rules for the use of SMR that are
 only found in RFC 6830.  I am suggesting adding a reference to 6830 at
 this point so readers know where to go to find more info on the SMR.


Agreed, I´ll add a sentence.

Further uses of SMRs are documented in [RFC6830].


 
  8. Section 5
 
  * I would suggest having a reference to both the MIP and the NEMO
  specs when discussing mobility.  LISP has the potential to
  operate in a manner conducive with NEMO if the xTR acts as the
  NEMO Mobile Router.
 
  Well if we do that then there are a ton of other cases where a xTR
  can be co-located with other functions (i.e. a simple reference is
  say a wifi AP). So singlingly out MIP/NEMO seems to be favoring
  these technologies versus others. Why would we want to do that?
 
  Plus, it raises questions more than simplifies the understanding of
  LISP. This is an intro document.
 
  What about adding the following sentence at the end of section 5?
 
  The decoupled identity and location provided by LISP allows it to
  operate with other layer 2 and layer 3 mobility solutions.

 The text talks about both network (NEMO) and host (MIP) mobility.  I am
 not concerned with LISP interacting with those protocols, I am thinking
 of how LISP replaces those protocols.  The descriptions in Section 5
 align with very well (i.e., the first paragraph describes LISP replacing
 NEMO and the second paragraph describes LISP replacing MIP).  My
 proposal was to simply add references in those paragraphs to the
 mobility protocol that LISP is approximately.

 I do like your proposed addition in order to highlight that LISP will
 not interfere with other mobility solutions.


What about adding two sentences at the end of each paragraph:

This functionality is similar to [RFC NEMO].
This functionality is similar to [RFC MIP] [RFC MIPv6].

 [snip]

 10. I am surprised that there are 2 Security Consideration
  sections (7  9).  I am even more surprised that one says
  Nothing new here and the other actually discusses potential
  issues with the LISP approach.
 
 
  My fault, Section 7 should be “LISP Security Considerations”
 
  Section 9 describes the security considerations for the document
  itself.

 I think maintaining two security consideration sections will be
 confusing.  Either document that *this* document introduces no new
 security issues or have the security considerations section summarize
 the security impacts of LISP.


Agreed, will do the latter (so Section 9 is now Section 7).



 Regards,
 Brian




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction

[Albert Cabellos]

Hi

Thank you very much for the review, please see inline my replies:

 On Jan 14, 2015, at 7:10 PM, Dino Farinacci farina...@gmail.com wrote:
 
 Here are some brief responses to your comments Brian. Thanks for doing the 
 throuogh review.
 
 On Jan 14, 2015, at 8:26 AM, Brian Haberman br...@innovationslab.net wrote:
 
 All,
I have completed by AD Evaluation of draft-ietf-lisp-introduction
 as a part of the IETF publication process.  I have some
 comments/questions that should be resolved prior to starting an IETF
 Last Call.  Please let me know if you have any questions on these...
 
 1. Section 1
 
 * I am going to try and short-circuit the inevitable question that will
 arise about the reference [Chiappa].  Since it is a web page, the RFC
 Editor will be concerned by its long-term stability.  Is that the best
 reference for that text?  Anything similar that has been published in a
 conference/journal/RFC/etc.?
 
 I will yield to the authors.

Unfortunately I´ve been unable to find a more “stable” publication. However the 
exact same document is cited in RFC4423 with the following “disclaimer”:

(…) the unpublished Internet Draft Endpoints and Endpoint Names [10] by Noel 
Chiappa (…)”

Please let me know if adding a similar sentence is enough.

 
 * The text uses the terms underlay and overlay without any context (in
 the summary bullets).  This is easily fixed by augmenting the text in
 the 2nd paragraph to identify which networks form the underlay and the
 overlay.
 
 Those terms aren't used very much in RFC 6830 because those terms seem to 
 become fashionable with the advent of nv03. If the authors want to continue 
 to use those terms, I have no problem with that, but would suggest that the 
 Definition of Terms section say that the underlay is what is referred to in 
 RFC 6830 as the underlying core routing system. And that an overlay is 
 the encapsulation relationship between ITRs, ETRs, PxTRs, and RTRs.

I think that the second paragraph already introduces many new and important 
concepts, what about updating the first two bullet points?

   o  RLOCs have meaning only in the underlay network, **that is the underlying 
core routing system.**

   o  EIDs have meaning only in the overlay network unless they are leaked into 
the underlay network. **The overlay is the encapsulation relationship between 
LISP-capable routers.**

 
 2. Section 3 (and a few times in 3.5) : s/inetrworking/internetworking/
 

Thanks for catching this typo.

 3. Section 3.2
 
 * Is it correct to say that EIDs are only routable at the edge?  This
 seems to contradict the text in section 3.5 that says EIDs may be
 injected in the global routing system.
 
 Well it depends on your reference point. If the overlay is the center of 
 perspective, then the global routing system is a non-LISP site relative to 
 the overlay. The whole point is that EIDs are routable where LISP is not 
 available. And that is true inside of a LISP site where packets are at a 
 point in the data-path pre-encapsulation or post-decapsulation.
 

What about changing the last sentence to:

Because of this, EIDs are usually routable at the edge (within LISP sites) or 
in the non-LISP Internet.

 * I find the PI and PA analogies misleading.  EIDs are global, but they
 may change their point of attachment.  If that occurs, you are not
 guaranteed that your EID space does not change.
 
 It is desirable that your EIDs do not change. But the scope of EID mobility 
 may be limited and if a legacy site wants to continue to use DHCP and address 
 addresses out of, say an enterprise address pool, it should be able to do 
 that while losing session survivability features. That is a decision for the 
 organization that is supporting mobility into its own domain.

I suggest removing both analogies (PI and PA), two sentences overall.

 
 * In the example, bullet four mistakenly says that the destination
 address of the outer header is set to RLOC_B2 (it should be RLOC_b1).
 

Thanks

 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel
 Routers) with no real description of how it functions or relates to ITRs
 and ETRs.
 
 Well there are references to it in RFC 6830 and there are many use-cases for 
 them which we are not allowed to reference since the drafts are not working 
 group documents.
 

What about extending the last sentence of the paragraph?

Typically such functions are implemented by Reencapsulating Tunnel Routers 
(RTRs), **An RTR can be thought as a router that first acts as an ETR by 
decapsulating packets and then as an ITR by encapsulating them towards another 
locator.**


 5. Section 3.4.3 makes reference to the LISP WG.  Given that this
 document will probably outlive the WG, I would suggest re-wording to
 remove a direct reference to the WG.

Updated sentence:

Many of the existing mechanisms to create distributed systems have been 
explored and considered for the Mapping System architecture:

 
 6. Section 3.4 has no discussion 

Re: [lisp] Proposing Encapsulation Format LCAF type

[Albert Cabellos]

Hi Luigi

 Is the WG OK to work on the proposed encoding and push the work on a more
general format to later times (i.e. after rechartering)?

I agree with the current format, existing data-planes are still a moving
target and it is hard to anticipate their requirements. Additionally some
requirements might result in multiple lookups.

Albert
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Fwd: I-D Action: draft-ietf-lisp-introduction-09.txt

[Albert Cabellos]

Hi all

-09 fixes English grammar in a paragraph.

Albert

-- Forwarded message --
From: internet-dra...@ietf.org
Date: Thu, Nov 13, 2014 at 7:43 PM
Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-09.txt
To: i-d-annou...@ietf.org
Cc: 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 Working
Group of the IETF.

Title   : An Architectural Introduction to the Locator/ID
Separation Protocol (LISP)
Authors : Albert Cabellos
  Damien Saucez
Filename: draft-ietf-lisp-introduction-09.txt
Pages   : 26
Date: 2014-11-13

Abstract:
   This document describes the architecture of the Locator/ID Separation
   Protocol (LISP), making it easier to read the rest of the LISP
   specifications and providing a basis for discussion about the details
   of the LISP protocols.  This document is used for introductory
   purposes, more details can be found in RFC6830, the protocol
   specification.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-introduction-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.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

[lisp] Fwd: I-D Action: draft-ietf-lisp-introduction-08.txt

[Albert Cabellos]

Hi all

We have just posted -08 version that includes editorial changes for
clarification and to address Ron’s comments.

Albert

-- Forwarded message --
From: internet-dra...@ietf.org
Date: Wed, Nov 12, 2014 at 5:19 PM
Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-08.txt
To: i-d-annou...@ietf.org
Cc: 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 Working
Group of the IETF.

Title   : An Architectural Introduction to the Locator/ID
Separation Protocol (LISP)
Authors : Albert Cabellos
  Damien Saucez
Filename: draft-ietf-lisp-introduction-08.txt
Pages   : 26
Date: 2014-11-12

Abstract:
   This document describes the architecture of the Locator/ID Separation
   Protocol (LISP), making it easier to read the rest of the LISP
   specifications and providing a basis for discussion about the details
   of the LISP protocols.  This document is used for introductory
   purposes, more details can be found in RFC6830, the protocol
   specification.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-introduction-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.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-introduction-06.txt

[Albert Cabellos]

Thanks!

Albert

On Fri, Oct 24, 2014 at 8:11 PM, Dino Farinacci farina...@gmail.com wrote:

 Hi Dino


 Thanks for your review. I am attaching -07 + diff (not published yet)
 where I have addressed all your comments, please let me know if you
 agree and we´ll proceed to publish it.


 I just looked at the changes, they all look good. A couple of nits:


 Add period at end of this sentence.


 Typo in blue.

   Map-Resolver:  A network infrastructure component that interfaces
  ITRs with the Mapping System by proxying queries and -in some
  cases- responses.


 I would say receive queries and sends negative replies.


 This is already explained in Map-Reply, at this point Map-Reply has
 not been introduced yet. I think that this way is clearer.


 Okay, fine.


 But why don't you order the messages first and then refer to them when you
 define the Map-Server and Map-Resolver afterwards?


 There is a circular dependency, then I won't be able to use the terms
 Map-Server/Map-Resolver when explaining what Map-Request/Map-Reply,
 etc are.


 Right, understand.

 [snip]


   Map-Request:  This message is used by ITRs or Map-Resolvers to
  resolve the mapping of a given EID.


 This message is also used by ETRs to request an ITR to do a Mapping System
 request. This message is also used by ITRs to probe the underlying path to
 an ETR.


 This is early in the document and I think that it is preferable to
 keep things simple. The fact that SMR/RLOC probing functionalities use
 a Map-Request type of message is not important when considering LISP's
 big picture. SMR/RLOC probing are explained in section 4 with the
 relevant context.


 Okay, agree.

 Albert
 draft-ietf-lisp-introduction-07.txt
 draft-ietf-lisp-introduction-07-from-6.diff.html


 I vote for you to publish. Thanks.

 Dino



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] draft-ietf-lisp-introduction - Design Principles and Use Cases

[Albert Cabellos]

Hi all

What about this (as a new item in section 2.1)?

* Pull Architecture: With this principle the network state is stored
at the control-plane -in a potentially distributed database- and
retrieved on-demand by the data-plane. Pull architectures allow to
push important routing mechanisms such as Traffic Engineering to the
control-plane, alleviating the data-plane. At the same time they
require of additional techniques to handle data-plane events, such as
network failures.

Albert

On Mon, Oct 13, 2014 at 4:31 PM, Dino Farinacci farina...@gmail.com wrote:

 The only remaining question is whether or not we want to add a bullet 
 concerning the push/pull model  Mapping database

 Well since a large portion of the document discusses the mapping system, I 
 would say yes.

 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-ietf-lisp-introduction-05 - Instance Identifiers and Namespaces

[Albert Cabellos]

Hi Ronald,

Thanks for your comment.

I don´t see how they are different namespaces.

LISP creates two namespaces (EIDs and RLOCs), Instance-ID helps you
separate the *EID namespace*, not create a new one.

Albert






On Sun, Oct 12, 2014 at 2:26 AM, Ronald Bonica rbon...@juniper.net wrote:
 Folks,

 AFAIKS, a LISP site can contain two hosts with the same EID (e.g., 
 192.0.2.1). LISP uses the Instance-ID to distinguish between the two hosts.

 If this is the case, does LISP really create two namespaces. Or does it 
 create:

 - one namespace for RLOCs
 - another namespace for each Instance-ID

 If the later, we should fix the document.

 Ron Bonica

 ___
 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-ietf-lisp-introduction - Design Principles and Use Cases

[Albert Cabellos]

Hi Ronald

Thanks for your comment.

I agree that none of such design principles are unique to LISP, but -I
think- you are reading them independently and they should be
considered the four of them *at the same time*. With this I expect
that the reader gets -very quickly- LISP's big picture.

I don´t think that pull is such a unique characteristic, DNS works
based on exactly the same principle: pull locators.

Albert



On Sun, Oct 12, 2014 at 3:32 AM, Dino Farinacci farina...@gmail.com wrote:
 Well everything tends to look the same but not in this case. This is the 
 first mapping database that is really fully specified and tested at the 
 network layer.

 Dino


 On Oct 11, 2014, at 9:20 PM, Ronald Bonica rbon...@juniper.net wrote:

 Dino,

 That too!

 However, the mapping database system is not entirely unique to LISP. Every 
 architecture that maps one address space to another needs a data base to 
 maintain mapping information. The part that is unique to LISP is how the 
 data is distributed

 Ron


 -Original Message-
 From: Dino Farinacci [mailto:farina...@gmail.com]
 Sent: Saturday, October 11, 2014 9:02 PM
 To: Ronald Bonica
 Cc: lisp@ietf.org
 Subject: Re: [lisp] draft-ietf-lisp-introduction - Design Principles and Use
 Cases

 On Oct 11, 2014, at 7:51 PM, Ronald Bonica rbon...@juniper.net wrote:

 In Section 2.1, we say that LISP is built on top of four basic design 
 principles:

  - Locator/Identifier split
  - Overlay architecture
  - Decoupled data and control-plane
  - Incremental deployability

 You left out one that is really important:

 - A Mapping Database System

 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] I-D Action: draft-ietf-lisp-introduction-05.txt

[Albert Cabellos]

Good point, thanks

We´ll do this

Albert

On Fri, Oct 3, 2014 at 11:04 AM, Luigi Iannone g...@gigix.net wrote:
 What I did in other documents is to explicitly put a pointer to RFC6830 but 
 also copy verbatim the section as an appendix.
 In this way the lazy reader will have the definitions at hand ;-)

 L.


 On 02 Oct 2014, at 02:05, Albert Cabellos albert.cabel...@gmail.com wrote:

 Ok, then I´ll add a sentence in the Introduction section pointing to
 the Definitions of Terms of RFC6830

 Albert

 On Thu, Oct 2, 2014 at 2:03 AM, Joel M. Halpern j...@joelhalpern.com wrote:
 While it is not a strict rule, it is usually better to point to a definition
 rather than copy it, and much better to point to it rather than to copy and
 modify it.

 Yours,
 Joel


 On 10/1/14, 7:48 PM, Albert Cabellos wrote:

 Hi Fabio

 Thanks for your comments, please find below our answers:

 On Fri, Sep 26, 2014 at 2:28 AM, Fabio Maino fma...@cisco.com
 wrote:


 Albert, Damien, this is a very good document, that I think fits
 very well with the charter requirements.  I like that you keep it
 short, dry, and to the point.

 From a structure perspective, I don't see a Definition of Terms
 section. Maybe you could point to RFC6830 definitions, or copy
 those needed in this document (XEID is possibly the only term that
 is not already in RFC6830 glossary). I like that you didn't use new
 terminology.


 Find below a proposed Definitions of Terms, We have used a
 simplified version of RFC6830,RFC6832,RFC6833 definitions, we don´t
 need so much detail and this way the text is lighter and easier to
 understand:

 ___
 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-introduction-05.txt

[Albert Cabellos]

Hi Dino

Thanks, I´ve removed the parts for which I agree, below my comments:

On Fri, Oct 3, 2014 at 6:40 PM, Dino Farinacci farina...@gmail.com wrote:

 Change supra to super. But saying super-linear is like saying that was 
 a long minute. ;-) I think you should say exponential slope.


 I think that the correct mathematical term is supralinear:

 http://en.wiktionary.org/wiki/supralinear

 I am not questioning the definition of supra linear, I just think we should 
 use exponential because we have done so so many times before. Not a big deal.


Ok, thanks for clarifying. Anyhow this part has been removed from the
updated introduction.


   In order to resolve a query LISP-DDT operates iteratively and in a
   similar way to the DNS.  DDT clients (usually Map-Resolvers) generate

 It may worth saying that DDT does not do recursive lookups like DNS but 
 does do iterative lookups like DNS.


 Why stating what DDT is not? I think that this way is shorter and clearer.

 Because if you state that DDT is DNS, then people may assume that recurisve 
 lookups are done as they are in DNS. DNS has recursive and iterative lookups. 
 DDT only borrowed the iterative lookup idea from DNS.

Ok, what about this:

In order to resolve a query LISP-DDT operates in a similar way to the
DNS but only supports iterative lookups.


   return a Map-Reply, also sent on the data-plane.  The active nature
   of RLOC-probing provides an effective mechanism to determine
   reachability and, in case of failure, switching to a different
   locator.  Furthermore the mechanism also provides useful RTT
   estimates of the delay of the path that can be used by other network
   algorithms.

 We should say that echo-noncing and RLOC-probing can work together. That is 
 if a nonce is not echoed, a ITR could RLOC-probe to determine if the path 
 is up (because the return bidirectional path may have went silent). Or, 
 when echo-noncing determines a forward path to an RLOC is up, RLOC-probes 
 can be suppressed to save sending extra messages.


 See my updated paragraph below:

 It is worth noting that RLOC probing and Echo-nonce can work together.
 Specifically if a nonce is not echoed, an ITR could RLOC-probe to
 determine if the path is up because the return bidirectional path may
 have failed. Alternatively, when echo-noncing determines a forward

 Or the the return path is not used. That is there is only a unidirectional 
 path.

 path to an RLOC is up, RLOC-probes can be suppressed to save messages.

 This part to explain suppressing RLOC-probes is good.


Ok, I´ve appended your sentence, see below:

Specifically if a nonce is not echoed, an ITR could RLOC-probe to
determine if the path is up because the return bidirectional path may
have failed or the return path is not used, that is there is only a
unidirectional path.

 Thanks a lot,
 Dino


Thanks!

Albert

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Updated Intro section for lisp-introduction

[Albert Cabellos]

Hi Christian

Thanks, see inline my comments:

On Thu, Oct 2, 2014 at 4:45 PM, Christian Cassar ccas...@cisco.com wrote:
 Hello Albert,

 I have been through the current version of the document, and it reads well - 
 thanks!

 I have added a few nits below - feel free to pick and choose:

 2.3 Data-plane

 In This header is created by the source end-host and remains unchanged.
 remains unchanged - is left unchanged by LISP data plane processing on 
 the ITR and ETR. (TTL processing, as part of IP forwarding, is done on that 
 header as usual.)


Ok, thanks.

 3.2.  RLOC Reachability

 You describe RLOC probing in this section which is expected. However, you may 
 also want to allude to RLOC probing in the previous Cache Management section 
 too; an ITR implementation can exploit RLOC probing to infer instances where 
 it might be sensible to refresh entries in a map cache.


What about adding the following sentence at the end of section 3.1:

Finally it is worth noting that in some cases an entry of the
map-cache can be proactively refreshed using the mechanisms described
in the section below.

 3.4. MTU Handling

 The Stateless comment is a tad misleading. I think the salient point in the 
 stateless mechanism is that the effective MTU is assumed from ITR's 
 perspective. The fact that ITR fragments packets that are too big, and can be 
 fragmented is common across both stateless and stateful mechanisms.


What about this:

Stateless:  With this mechanism the effective MTU is assumed from the
ITR's perspective, in case that a packet is too big reassembly is
typically performed at the destination host.

 Couple of typos in here (defeines and framgented).

 

 The rest are exclusively style/spelling comments - feel free to pick and 
 choose. Oh, and I should add that English is my second language (as if it 
 weren't obvious already) - so you would do better to get some one with a good 
 command of the language to give it a once over.


Thanks! We´ll apply all your suggestions.

 LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
 RLOCs (Routing LOCators), both are -typically, but not limited to-
 syntactically identical to the current IPv4 and IPv6 addresses.  EIDs
 are used to uniquely identify nodes irrespective of their topological
 location and are typically routed intra-domain. RLOCs are assigned
 topologically to network attachment points and are typically routed
 inter-domain.  With LISP, the edge of the Internet -where the nodes
 are connected- and the core -where inter-domain routing occurs- are
 architecturally separated and interconnected by LISP-capable routers.

 The word 'architecturally' doesn't seem to add much here, and 'are' might be 
 replaced by 'can be' - for example my IPv6 host may be reachable over LISP 
 over IPv4 and directly over IPv6.


Agreed, what about logically?

 Thanks again
 Christian


Thanks

Albert

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Updated Intro section for lisp-introduction

[Albert Cabellos]

Hi all

I would like to ask the WG about this section, should we we describe
the problem that LISP is trying to solve in the Introduction section?

Some people suggest that we should while others that it provides too
many details.

Below you can find a sample description of the problem statement.

Thanks

Albert

   There is a rough consensus that the Internet routing and addressing
   system is facing severe scalability issues [RFC4984].  Specifically,
   the growth in the size of the routing tables of the Default-Free Zone
   (DFZ) is accelerating and showing a supra-linear slope [DFZ].  The
   main driving force behind this growth is the de-aggregation of BGP
   prefixes, which results from the existing BGP multihoming and traffic
   engineering mechanisms that are used -at the time of this writing- on
   the Internet, as well as non-aggregatable address allocations.

   This issue has two profound implications, on the one hand Internet
   core routers are exposed to the network dynamics of the edge.  For
   instance this typically leads to an increased amount of BGP UPDATE
   messages (churn), which results in additional processing requirements
   of Internet core routers in order to timely compute the DFZ RIB.
   Secondly, the supra-linear growth imposes strong requirements on the
   size of the memory storing the DFZ FIB.  Both aspects lead to an
   increase on the development and production cost of high-end routers,
   and it is unclear if the semiconductor and router manufacturer
   industries will be able to cope, in the long-term, with such
   stringent requirements in a cost-effective way[RFC4984].

   Although this important scalability issue is relatively new, the
   architectural reasons behind it are well-known many years ago.
   Indeed, and as pointed out by [Chiappa], IP addresses have overloaded
   semantics.  Currently, IP addresses both identify the topological
   location of a network attachment point as well as the node's
   identity.  However, nodes and routing have fundamentally different
   requirements, routing systems require that addresses are aggregatable
   and have topological meaning, while nodes require to be identified
   independently of their current location.

On Thu, Oct 2, 2014 at 1:53 AM, Albert Cabellos
albert.cabel...@gmail.com wrote:
 Hi all

 This is the proposed Introduction following the comments on the list:

 This document introduces the Locator/ID Separation Protocol (LISP)
 [RFC6830] architecture, its main operational mechanisms and its design
 rationale. Fundamentally, LISP is built following a well-known
 architectural idea: decoupling the IP address overloaded semantics.
 Indeed and as pointed out by [Chiappa], currently IP addresses both
 identify the topological location of a network attachment point as
 well as the node's identity.  However, nodes and routing have
 fundamentally different requirements, routing systems require that
 addresses are aggregatable and have topological meaning, while nodes
 require to be identified independently of their current location.

 LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
 RLOCs (Routing LOCators), both are -typically, but not limited to-
 syntactically identical to the current IPv4 and IPv6 addresses.  EIDs
 are used to uniquely identify nodes irrespective of their topological
 location and are typically routed intra-domain. RLOCs are assigned
 topologically to network attachment points and are typically routed
 inter-domain.  With LISP, the edge of the Internet -where the nodes
 are connected- and the core -where inter-domain routing occurs- are
 architecturally separated and interconnected by LISP-capable routers.
 LISP also introduces a publicly accessible database, called the
 Mapping System, to store and retrieve mappings between identity and
 location.  LISP-capable routers exchange packets over the Internet
 core by encapsulating them to the appropriate location.

 By taking advantage of such separation between location and identity,
 LISP offers Traffic Engineering, multihoming, and mobility among
 others benefits. Additionally, LISP’s approach to solve the routing
 scalability problem [RFC4984] is that with LISP the Internet core is
 populated with RLOCs which can be quasi-static and highly
 aggregatable, hence scalable [Quoitin].

 It is important to note that this document does not specify or
 complement the LISP protocol.  The interested reader should refer to
 the main LISP specification [RFC6830] and the complementary documents
 [RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], [RFC6836] for the
 protocol specifications along with the LISP deployment guidelines
 [RFC7215].

 Albert

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Albert Cabellos]

Hi Fabio

Thanks for your comments, please find below our answers:

On Fri, Sep 26, 2014 at 2:28 AM, Fabio Maino fma...@cisco.com wrote:

 Albert, Damien,
 this is a very good document, that I think fits very well with the charter 
 requirements.  I like that you keep it short, dry, and to the point.

 From a structure perspective, I don't see a Definition of Terms section. 
 Maybe you could point to RFC6830 definitions, or copy  those needed in this 
 document (XEID is possibly the only term that is not already in RFC6830 
 glossary). I like that you didn't use new terminology.


Find below a proposed Definitions of Terms, We have used a
simplified version of RFC6830,RFC6832,RFC6833 definitions, we don´t
need so much detail and this way the text is lighter and easier to
understand:

Routing Locator (RLOC):   An RLOC is an IPv4 or IPv6 address of an
Egress Tunnel Router (ETR). Typically, RLOCs are numbered from
topologically aggregatable blocks that are assigned to a site at each
point to which it attaches to the global Internet.

Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
IPv6) value used in the source and destination address fields of the
first (most inner) LISP header of a packet.  The host obtains a
destination EID the same way it obtains a destination address today,
for example, through a Domain Name System (DNS

EID-Prefix:   An EID-Prefix is a power-of-two block of EIDs that are
allocated to a site by an address allocation authority. Ingress Tunnel
Router (ITR):   An ITR is a router that resides in a LISP site.
Packets sent by sources inside of the LISP site to destinations
outside of the site are candidates for encapsulation by the ITR.

Egress Tunnel Router (ETR):   An ETR is a router that accepts an IP
packet where the destination address in the outer IP header is one
of its own RLOCs.  The router strips the outer header and forwards
the packet based on the next IP header found.

LISP Proxy Ingress Tunnel Router (Proxy-ITR):  Proxy-ITRs are used to
provide connectivity between sites that use LISP EIDs and those that
do not.  They act as gateways between those parts of the Internet that
are not using LISP (the legacy Internet

LISP Proxy Egress Tunnel Router (Proxy-ETR):  Proxy-ETRs provide a
LISP (routable or non-routable EID) site's ITRs with the ability to
send packets to non-LISP sites in cases where unencapsulated packets
(the default mechanism) would fail to be delivered.

Map-Server:   A network infrastructure component that learns of
EID-Prefix mapping entries from an ETR and publishes these
EID-Prefixes in a mapping database.

Map-Resolver:   A network infrastructure component that find
appropriate EID-to-RLOC mappings by consulting the mapping database
system.


 Below are my comments, that you may want to address with the next rev.

 Thanks!
 Fabio




 Network Working GroupA. Cabellos
 Internet-Draft UPC-BarcelonaTech
 Intended status: Informational   D. Saucez (Ed.)
 Expires: March 26, 2015INRIA
   September 22, 2014

  An Architectural Introduction to the LISP Location-Identity Separation
  System
   draft-ietf-lisp-introduction-05.txt

 Abstract

This document describes the Locator/ID Separation Protocol (LISP)
architecture, its main operational mechanisms as well as its design
rationale.


 You should include here a  sentence that says this is an introduction and a 
 guide to the rest of the LISP specification. I think something along the 
 lines of this sentence taken from the charter:

 This document will describe the
 architecture of the entire LISP system, making it easier to read the
 rest of the LISP specifications and providing a basis for discussion
 about the details of the LISP protocols.



Since other people have similar issues with the abstract I´ll send –in
a separate email- a new version to see if we can agree.



 Requirements Language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in RFC 2119 [RFC2119].

 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 http://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 

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

[Albert Cabellos]

Hi Luigi

Thanks for your comments, please see below our answers:

On Fri, Sep 26, 2014 at 4:47 PM, Luigi Iannone g...@gigix.net wrote:
 Hi Albert, Damien,

 thank you for this new document. It is very easy to read and is pretty
 clear.

 Hereafter my personal comments/review.

 ciao

 Luigi






 Network Working GroupA. Cabellos
 Internet-Draft UPC-BarcelonaTech
 Intended status: Informational   D. Saucez (Ed.)
 Expires: March 26, 2015INRIA
   September 22, 2014


  An Architectural Introduction to the LISP Location-Identity Separation
  System
   draft-ietf-lisp-introduction-05.txt

 Abstract

This document describes the Locator/ID Separation Protocol (LISP)
architecture, its main operational mechanisms as well as its design
rationale.

 This abstract states the content of the document but not its purpose.


Since other people have similar issues with the abstract I´ll send –in
a separate email- a new version to see if we can agree.


 Requirements Language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in RFC 2119 [RFC2119].

 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 http://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 March 26, 2015.

 Copyright Notice

Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of



 Cabellos  Saucez (Ed.)  Expires March 26, 2015 [Page 1]

 Internet-Draft  LISP Introduction September 2014


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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

 Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  LISP Architecture . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
  2.2.  Overview of the Architecture  . . . . . . . . . . . . . .   4
  2.3.  Data-Plane  . . . . . . . . . . . . . . . . . . . . . . .   7
2.3.1.  LISP encapsulation  . . . . . . . . . . . . . . . . .   7
2.3.2.  LISP Forwarding State . . . . . . . . . . . . . . . .   8
  2.4.  Control-Plane . . . . . . . . . . . . . . . . . . . . . .   9
2.4.1.  LISP Mappings . . . . . . . . . . . . . . . . . . . .   9
2.4.2.  Mapping System Interface  . . . . . . . . . . . . . .   9
2.4.3.  Mapping System  . . . . . . . . . . . . . . . . . . .  10
  2.5.  Internetworking Mechanisms  . . . . . . . . . . . . . . .  13
3.  LISP Operational Mechanisms . . . . . . . . . . . . . . . . .  13
  3.1.  Cache Management  . . . . . . . . . . . . . . . . . . . .  14
  3.2.  RLOC Reachability . . . . . . . . . . . . . . . . . . . .  14
  3.3.  ETR Synchronization . . . . . . . . . . . . . . . . . . .  15
  3.4.  MTU Handling  . . . . . . . . . . . . . . . . . . . . . .  16
4.  Mobility  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
5.  Multicast . . . . . . . . . . . . . . . . . . . . . . . . . .  17
6.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  18
  7.1.  Traffic Engineering . . . . . . . . . . . . . . . . . . .  18
  7.2.  LISP for IPv6 Transition  . . . . . . . . . . . . . . . .  19
  7.3.  LISP for Network Virtualization . . . . . . . . . . . . .  19
  7.4.  LISP for Virtual Machine Mobility in Data Centers . . . .  20
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
9.  IANA Considerations . . 

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

[Albert Cabellos]

Hi Dino

Thanks for your comments, please find below our answers:

On Fri, Sep 26, 2014 at 9:01 PM, Dino Farinacci farina...@gmail.com wrote:
 We´ll gather more feedback and produce a new version before cut-off,
 please review and comment ASAP.

 Thanks Albert and Damien for pulling a multitude of comments together to get 
 this draft out. Here are my comments on -05. Your text comes first and is 
 indented and my comments follow.

 There are places in the spec where the text is just blantantly wrong. I have 
 commented on those and offered the truth and contributed text.   ;-)

  An Architectural Introduction to the LISP Location-Identity Separation
  System
   draft-ietf-lisp-introduction-05.txt

 To not have too many variations of titling LISP, could this title simply be:

 An Architectural Introduction to the Locator/ID Separation Protocol 
 (LISP)



Ok


 Abstract

This document describes the Locator/ID Separation Protocol (LISP)
architecture, its main operational mechanisms as well as its design
rationale.

 I would add This document is used for introduction purposes. More detail is 
 available in the protocol specifications which are references in this 
 introduciton document.

 What do you think?


Since other people have similar issues with the abstract I´ll send –in
a separate email- a new version to see if we can agree.

 Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  LISP Architecture . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
  2.2.  Overview of the Architecture  . . . . . . . . . . . . . .   4
  2.3.  Data-Plane  . . . . . . . . . . . . . . . . . . . . . . .   7
2.3.1.  LISP encapsulation  . . . . . . . . . . . . . . . . .   7

 Capitalize Encapsulation.

2.3.2.  LISP Forwarding State . . . . . . . . . . . . . . . .   8
  2.4.  Control-Plane . . . . . . . . . . . . . . . . . . . . . .   9
2.4.1.  LISP Mappings . . . . . . . . . . . . . . . . . . . .   9
2.4.2.  Mapping System Interface  . . . . . . . . . . . . . .   9
2.4.3.  Mapping System  . . . . . . . . . . . . . . . . . . .  10
  2.5.  Internetworking Mechanisms  . . . . . . . . . . . . . . .  13
3.  LISP Operational Mechanisms . . . . . . . . . . . . . . . . .  13
  3.1.  Cache Management  . . . . . . . . . . . . . . . . . . . .  14
  3.2.  RLOC Reachability . . . . . . . . . . . . . . . . . . . .  14
  3.3.  ETR Synchronization . . . . . . . . . . . . . . . . . . .  15
  3.4.  MTU Handling  . . . . . . . . . . . . . . . . . . . . . .  16
4.  Mobility  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
5.  Multicast . . . . . . . . . . . . . . . . . . . . . . . . . .  17
6.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  18
  7.1.  Traffic Engineering . . . . . . . . . . . . . . . . . . .  18
  7.2.  LISP for IPv6 Transition  . . . . . . . . . . . . . . . .  19

 Could you title it IPv6 Co-Existence?


Ok.

  7.3.  LISP for Network Virtualization . . . . . . . . . . . . .  19
  7.4.  LISP for Virtual Machine Mobility in Data Centers . . . .  20

 These two look two similar. Should 7.3 just say LISP for Virtual Private 
 Networks?


Ok.

 1.  Introduction

There is a rough consensus that the Internet routing and addressing
system is facing severe scalability issues [RFC4984].  Specifically,
the growth in the size of the routing tables of the Default-Free Zone
(DFZ) is accelerating and showing a supra-linear slope [DFZ].  The

 Change supra to super. But saying super-linear is like saying that was a 
 long minute. ;-) I think you should say exponential slope.


I think that the correct mathematical term is supralinear:

http://en.wiktionary.org/wiki/supralinear

main driving force behind this growth is the de-aggregation of BGP
prefixes, which results from the existing BGP multihoming and traffic
engineering mechanisms that are used -at the time of this writing- on
the Internet, as well as non-aggregatable address allocations.

This issue has two profound implications, on the one hand Internet
core routers are exposed to the network dynamics of the edge.  For
instance this typically leads to an increased amount of BGP UPDATE
messages (churn), which results in additional processing requirements
of Internet core routers in order to timely compute the DFZ RIB.
Secondly, the supra-linear growth imposes strong requirements on the
size of the memory storing the DFZ FIB.  Both aspects lead to an
increase on the development and production cost of high-end routers,
and it is unclear if the semiconductor and router manufacturer
industries will be able to cope, in the long-term, with 

[lisp] Updated abstract for lisp-introduction

[Albert Cabellos]

Hi all

This is the new proposed abstract:

This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introduction
purposes, more details is available in the protocol specification.

Albert

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Updated Intro section for lisp-introduction

[Albert Cabellos]

Hi all

This is the proposed Introduction following the comments on the list:

This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its design
rationale. Fundamentally, LISP is built following a well-known
architectural idea: decoupling the IP address overloaded semantics.
Indeed and as pointed out by [Chiappa], currently IP addresses both
identify the topological location of a network attachment point as
well as the node's identity.  However, nodes and routing have
fundamentally different requirements, routing systems require that
addresses are aggregatable and have topological meaning, while nodes
require to be identified independently of their current location.

LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
RLOCs (Routing LOCators), both are -typically, but not limited to-
syntactically identical to the current IPv4 and IPv6 addresses.  EIDs
are used to uniquely identify nodes irrespective of their topological
location and are typically routed intra-domain. RLOCs are assigned
topologically to network attachment points and are typically routed
inter-domain.  With LISP, the edge of the Internet -where the nodes
are connected- and the core -where inter-domain routing occurs- are
architecturally separated and interconnected by LISP-capable routers.
LISP also introduces a publicly accessible database, called the
Mapping System, to store and retrieve mappings between identity and
location.  LISP-capable routers exchange packets over the Internet
core by encapsulating them to the appropriate location.

By taking advantage of such separation between location and identity,
LISP offers Traffic Engineering, multihoming, and mobility among
others benefits. Additionally, LISP’s approach to solve the routing
scalability problem [RFC4984] is that with LISP the Internet core is
populated with RLOCs which can be quasi-static and highly
aggregatable, hence scalable [Quoitin].

It is important to note that this document does not specify or
complement the LISP protocol.  The interested reader should refer to
the main LISP specification [RFC6830] and the complementary documents
[RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], [RFC6836] for the
protocol specifications along with the LISP deployment guidelines
[RFC7215].

Albert

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Updated Intro section for lisp-introduction

[Albert Cabellos]

I copied it from Word, will be removed for the draft.

Thanks!

Albert

On Thu, Oct 2, 2014 at 2:36 AM, Dino Farinacci farina...@gmail.com wrote:
 The text content looks good but why so much mid sentence hyphenation?

 Dino


 On Oct 1, 2014, at 4:53 PM, Albert Cabellos albert.cabel...@gmail.com 
 wrote:

 Hi all

 This is the proposed Introduction following the comments on the list:

 This document introduces the Locator/ID Separation Protocol (LISP)
 [RFC6830] architecture, its main operational mechanisms and its design
 rationale. Fundamentally, LISP is built following a well-known
 architectural idea: decoupling the IP address overloaded semantics.
 Indeed and as pointed out by [Chiappa], currently IP addresses both
 identify the topological location of a network attachment point as
 well as the node's identity.  However, nodes and routing have
 fundamentally different requirements, routing systems require that
 addresses are aggregatable and have topological meaning, while nodes
 require to be identified independently of their current location.

 LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
 RLOCs (Routing LOCators), both are -typically, but not limited to-
 syntactically identical to the current IPv4 and IPv6 addresses.  EIDs
 are used to uniquely identify nodes irrespective of their topological
 location and are typically routed intra-domain. RLOCs are assigned
 topologically to network attachment points and are typically routed
 inter-domain.  With LISP, the edge of the Internet -where the nodes
 are connected- and the core -where inter-domain routing occurs- are
 architecturally separated and interconnected by LISP-capable routers.
 LISP also introduces a publicly accessible database, called the
 Mapping System, to store and retrieve mappings between identity and
 location.  LISP-capable routers exchange packets over the Internet
 core by encapsulating them to the appropriate location.

 By taking advantage of such separation between location and identity,
 LISP offers Traffic Engineering, multihoming, and mobility among
 others benefits. Additionally, LISP’s approach to solve the routing
 scalability problem [RFC4984] is that with LISP the Internet core is
 populated with RLOCs which can be quasi-static and highly
 aggregatable, hence scalable [Quoitin].

 It is important to note that this document does not specify or
 complement the LISP protocol.  The interested reader should refer to
 the main LISP specification [RFC6830] and the complementary documents
 [RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], [RFC6836] for the
 protocol specifications along with the LISP deployment guidelines
 [RFC7215].

 Albert

 ___
 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-ietf-lisp-introduction-05.txt

[Albert Cabellos]

Hi all

Below you can find the -05 version of draft-ietf-lisp-introduction. We
have changed the structure and content based on the feedback posted on
the list

We´ll gather more feedback and produce a new version before cut-off,
please review and comment ASAP.

Albert


-- Forwarded message --
From:  internet-dra...@ietf.org
Date: Mon, Sep 22, 2014 at 10:06 PM
Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt
To: i-d-annou...@ietf.org
Cc: 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
Working Group of the IETF.

Title   : An Architectural Introduction to the LISP
Location-Identity Separation System
Authors : Albert Cabellos
  Damien Saucez
Filename: draft-ietf-lisp-introduction-05.txt
Pages   : 24
Date: 2014-09-22

Abstract:
   This document describes the Locator/ID Separation Protocol (LISP)
   architecture, its main operational mechanisms as well as its design
   rationale.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-introduction-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.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-ietf-lisp-introduction-04 (Part 1)

[Albert Cabellos]

Hi Ron,

Thanks for your comments, please see my reply below:

On Wed, Aug 6, 2014 at 7:58 PM, Ronald Bonica rbon...@juniper.net wrote:
 Folks,

 The following are a few comments regarding draft-ietf-lisp-introduction-04. 
 Expect further comments in the next few days.

 - Section 1 adds no value. I agree with the editor's suggestion to remove.

 - Section 2 is empty. So clearly, I agree with the editor's suggestion to 
 remove.

 - Section 3 contains a few broken definitions. But sooner or later, you will 
 need a Glossary. So, I disagree with the editor's suggestion to remove the 
 entire section. Please change the name of this section from Initial 
 Glossary to Glossary or Terminology. Then delete its contents. Then 
 import whatever definitions you need, verbatim, from RFCs 6830-6836. This 
 should cover most of the terminology that you need. It will also prevent you 
 from redefining words. If you find that you still need to define a few terms, 
 please do so.


Agreed, we should use the terminology as defined in RFCs 68030-6836.
This will actually make the rest of the RFCs easier to read, one of
the goals of LISP-INTRO.

 - Section 4 adds no value. I agree with the editor's suggestion to remove.

 - Section 5 adds no value. I agree with the editor's suggestion to remove.

 - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same 
 sense that MPLS does. It's quite different.


RFC6830 states that LISP offers TE.

Albert

 - Section 7.4 adds no value. I agree with the editor's suggestion to remove.

 - Section 7.5 is not in charter. I agree with the editor's suggestion to 
 remove.

 - Section 7.7 is not in charter. I agree with the editor's suggestion to 
 remove.

 - Section 7.8 adds no value. I agree with the editor's suggestion to remove.

 - Appendix A is redundant with Section 3. I agree with the editor's 
 suggestion to remove

 - Appendix B contains interesting information, but does not contribute to the 
 goals of the draft. I agree with the editor's suggestion to remove it.

 - Please add a short Introduction before the Glossary. It should read as 
 follows:

 The Internet is experiencing problems A, B and C. LISP solves this problem 
 by doing D, E and F. LISP will solve A, B and C because []

D, E, and F distinguish LISP from existing routing protocols. The 
 architectural tradeoffs associated with D, E and F are [].


 Standby for more comments.



 Ron Bonica

 ___
 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-ietf-lisp-introduction-04 (Part 2)

[Albert Cabellos]

Hi Ron



On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica rbon...@juniper.net wrote:
 Folks,

 The following text is lifted from Section 6.1. At best, it is difficult to 
 parse. At worst, it is incorrect. Is there a better way to distinguish 
 between an IED and a LOC?


What about stating that RLOCs are topologically assigned to network
attachment points while EIDs are independent of the topology and used
to identify devices.

Albert

Rn

 The second key concept is that if one wants to be as forward-looking as 
 possible, conceptually one should think of the two kinds of names  (EIDs and 
 RLOCs) as naming different classes of entities.

  On the one hand, EIDs are used to name nodes - or rather, their end- end 
 communication entities.  RLOC(s), on the other hand, name interfaces, i.e. 
 places to which the system of routers sends packets.

  This distinction, the formal recognition of different kinds of entities 
 (endpoints and interfaces), and their association with the two different 
 classes of names, is also important.  Clearly recognizing interfaces and 
 endpoints as distinctly separate classes of objects is another improvement to 
 the existing Internet  architecture.



 ___
 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] Fwd: I-D ACTION:draft-ietf-lisp-introduction-04.txt

[Albert Cabellos]

Hi Marc

Thanks for your comments, we will indeed keep a long list of
references so that the INTRO document gives -some sort of- structure
to all the RFCs/WG documents and hence, are easier to read.

We agree with you, we should avoid too many details (the spec already
provides them) and explain the main LISP building blocks and how they
relate.

Albert

On Wed, Jul 30, 2014 at 10:28 AM, Marc Binderberger m...@sniff.de wrote:
 Hello Albert and Damien,

 quite a document!

 I'm looking forward for a version where your Editor's suggestions are
 implemented. I agree with the suggestions.

 What I do like - and hope it will be maintained in future versions - is the
 lot of references. It's a great read (I regularly get lost in looking up the
 referenced RFCs ;-)

 In part II the text sometimes is very detailed - an example is section 13.x:
 what fields are contained in the messages is described in the particular RFCs
 and I don't see a gain describing it here again, even briefly. In this sense
 I support all suggestions that simplify text. From an introduction text I
 would expect it explains the building blocks like MR, MS, iTR and eTR (to
 stay with the example of the mapping system) and what messages exist in
 between. And then a reference to the particular RFCs for details.

 Nevertheless, overall an interesting read.


 Regards, Marc







 On Wed, 16 Jul 2014 12:47:40 -0400, Joel M. Halpern wrote:
 The chairs and listed authors are happy to call the WGs attention to the
 latest revision of the LISP Introduction draft.
 If you can take a look at this before the meeting in Toronto, that would be
 good.
 Our apologies for the late notice.

 Yours,
 Joel


  Original Message 
 Subject: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt
 Date: Wed, 16 Jul 2014 09:40:43 -0700
 From: internet-dra...@ietf.org
 To: i-d-annou...@ietf.org
 CC: 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 Working
 Group of the IETF.

 Title : An Architectural Introduction to the LISP
 Location-Identity Separation System
 Author(s) : D. Saucez, et al
 Filename  : draft-ietf-lisp-introduction
 Pages : 59
 Date  : 2014-07-16

This document is an introductory overview of the Locator/ID
Separation Protocol, it describes the major concepts and functional
sub-systems of LISP and the interactions between them.


 A URL for this Internet-Draft is:
 https://www.ietf.org/internet-drafts/draft-ietf-lisp-introduction-04.txt

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 Below is the data which will enable a MIME compliant mail reader
 implementation to automatically retrieve the ASCII version of the
 Internet-Draft.



 ___
 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] Comments to draft-ietf-lisp-introduction-04.txt

[Albert Cabellos]

Hi Dino

I´ve noted all the comments for which we both agree, please see my
comments below:

On Mon, Jul 28, 2014 at 6:24 PM, Dino Farinacci farina...@gmail.com wrote:
 See my comments inline. The draft text comes first and is indented and my 
 comments follow. I included only draft text that I have comments on. Thanks.

 1.  Prefatory Note


[snip]


normally be in an architecture document (e.g. the architectural
design principles used in LISP, and the design considerations behind
various components and aspects of the LISP system) is in the second
document, the 'Architectural Perspective on LISP' document.
[I-D.ietf-lisp-perspective]

 What is the plan for this document?

This is a non-WG document and I suggest not to cite it.

[snip]


 7.3.  Traffic Engineering

{{Suggestion by editors: Merge this section with the previous one, TE
is not practical without multihoming}}

 Well I think when you define and talk about ITRs and ETRs, and their 
 interworking counter-parts PITRs and PETRs, that the mention of RTRs is a 
 good place to introduce the concept. Then you can say how RTRs can do TE, 
 even if they are reached via multiple RLOCs in an RLOC-set.

lisp-te is not part of the WG and I suggest to stick to WG items. We
can include them in the use-cases appendix.



 7.4.  Routing

{{Suggestion by editors: Remove this section, LISP is not a routing
protocol.}}

 Agree 100%. LISP is an overlay and it depends on the routing system that it 
 runs over. Nothing else should be stated. How LISP uses the underlay to get 
 more efficient paths is what could be listed in the use-case section when 
 RLOC selection, Segment Routing, and OAM may be mentioned.

Ok, I also think that it makes sense to add them in the use-cases.


 7.5.  Mobility

{{Suggestion by editors: Remove this section, mobility is not in
charter.}}

 Mobility from a host perspective is not in the charter. And putting LISP-MN 
 in hosts is not in the charter but general IP address (i.e. EID mobility is). 
 We have a considerable amount of text in RFC 6830 that talks about mobility. 
 And furthermore, since multi-homing is in the charter, when one changes  an 
 RLOC address to connect to a new provider, that is, in effect, a mobility 
 event.

Good point! We´ll indeed mention it.

[snip]


 8.2.3.  Indexing Sub-system

{{suggestion by editor: rename the section to DDT}}

 We have to be careful here because ALT is in RFC stages and DDT is not even a 
 working group document yet. We know the future is DDT, but the future will 
 also have other/newer approaches as well.


DDT is an expired WG document
(https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/).

[snip]


 15.2.2.  LISP-NAT

{{Suggestion by editors: Remove this section, LISP-NAT is not a WG
document neither an inter-networking mechanisms.}}

 I agree. It is a suggestion in the interworking spec but the deployment spec 
 does not recommend to use it so PxTRs is what we should focus on.

 15.3.  Use Through NAT Devices

{{Suggestion by editors: Remove this section, LISP-NAT is not a WG
document neither an inter-networking mechanisms.}}

 This is meant to describe NAT-traversal not LISP-NAT for interworking. I 
 think the problem is important to solve but just explain what I said above 
 about how RLOCs can be private or public and the Map-Servers can teach the 
 xTRs what their global RLOC addresses are.

You mean section 8.4 of RFC6830?

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt

[Albert Cabellos]

Hi

As Luigi said, we included some minor changes as well as suggestions for
more structural changes. The idea is to discuss them during the WG meeting.

This is the first edit after the interim meeting.
Albert


On Thu, Jul 17, 2014 at 5:15 PM, Dino Farinacci farina...@gmail.com wrote:

  Like Joel, I would like to invite people read the document despite the
 late submission.

 One clarification, is this the first edit after the interim meeting we had
 in Virgina last year?

 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] I-D ACTION:draft-ietf-lisp-introduction-04.txt

[Albert Cabellos]

Hi Dino

I assume you mean this:

http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=draft-ietf-lisp-introduction-04.txt

If not please let me know

Albert


On Thu, Jul 17, 2014 at 10:06 PM, Dino Farinacci farina...@gmail.com
wrote:

 Could someone supply a diff of the changes between the two -04 versions?

 Dino

 On Jul 17, 2014, at 12:57 PM, Albert Cabellos albert.cabel...@gmail.com
 wrote:

  Hi
 
  As Luigi said, we included some minor changes as well as suggestions for
 more structural changes. The idea is to discuss them during the WG meeting.
 
  This is the first edit after the interim meeting.
 
  Albert
 
 
  On Thu, Jul 17, 2014 at 5:15 PM, Dino Farinacci farina...@gmail.com
 wrote:
   Like Joel, I would like to invite people read the document despite the
 late submission.
 
  One clarification, is this the first edit after the interim meeting we
 had in Virgina last year?
 
  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] https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/

[Albert Cabellos]

+1

Albert

On 21/03/2014 8:26, Florin Coras wrote:

I think the draft is ready to go to the IESG.

Florin

On 03/20/2014 07:26 PM, Joel M. Halpern wrote:
The draft LISP EID Block has been revised to reflect the WG 
discussion and comments received.


This starts a last call for this document, ending April 4, 2014.
Please review thisdocument and indicate to the email lsit whether 
there are issues or you think it is complete and ready to go to the 
IESG.


This document is a companion to draft-iannone-lisp-eid-block-mgmnt-03.

Yours,
Joel

___
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] Welcome a new co-chair

[Albert Cabellos]

Congrats Luigi!

Albert

On 18/03/2014 17:51, Sharon Barkai wrote:

Congratulations.

--szb


On Mar 18, 2014, at 7:58, Brian Haberman br...@innovationslab.net wrote:

All,
 For those of you who have not noticed, I have added Luigi Iannone
as a third co-chair.  I want to thank Luigi for agreeing to take on this
role.

 Apologies for not announcing this sooner.  Welcome, Luigi!

Regards,
Brian

___
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] WGLC draft-ietf-lisp-threats-08

[Albert Cabellos]

Hi,

On 06/12/2013 0:05, Damien Saucez wrote:

[snip]

Right, thanks. What about recommending that each nonce should be used 
at least once? So that a nonce can´t be overwritten if it has not 
been used.




Isn't that the definition of a nonce? I don't see how it helps.

Imagine

- Legit sends Nonce1
- Bad guy sends Nonce2 with spoof address of Legit
- Nonce1 arrives, but it is too late, it has been overridden by Nonce2
already so the return with Nonce1is just ignored.



Ok thanks!

Albert
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WGLC draft-ietf-lisp-threats-08

[Albert Cabellos]

Hi,

On 04/12/2013 22:40, Damien Saucez wrote:

[snip]

* Section 4.3.2.2-RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.



I think the analysis is complementary to the recommendation.  In
RFC6830, no reason is given about why rate limit, here it shows why
this is recommended.

I agree, but the text seems to suggest that the amplification attack 
scales linearly and it is bounded to the maximum bandwidth (in control 
messages per second) of the attacker, this is not true. The attack is 
bounded by the rate-limit set at the xTR.




* Section 4.3.2.3-I´m having a hard time understanding this attack,
even under attack, the ETR will reply with the real nonce, at least
once. Probably I´m missing something.




sure but if an attacker floods with random nonce, then when the node
will answer with the real nonce, it will already have been changed to
another one sent by the attacker.



Right, thanks. What about recommending that each nonce should be used at 
least once? So that a nonce can´t be overwritten if it has not been used.



* Section 4.4.1- In some cases the SMR-invoked Map-Request is sent
through the mapping system (not directly to the source RLOC), in this
case the attack is still effective and involves the Mapping System, the
Map-Server and the xTR (if operating in non-proxy mode).



I am not sure I understand your question here.



I´m referring to this paragraph:

  The Map-Request message may also contain the SMR bit.  Upon reception
   of a Map-Request message with the SMR bit, an ETR must return to the
   source of the Map-Request message a Map-Request message to retrieve
   the corresponding mapping.  This raises similar problems as the RLOC
   record P bit discussed above except that as the Map-Request messages
   are smaller than Map-Reply messages, the risk of amplification
   attacks is reduced. 

In some cases the SMR-invoked Map-Request is sent through the Mapping 
System (RFC6830):


  If the source Locator is the only
   Locator in the cached Locator-Set, the remote ITR SHOULD send a
   Map-Request to the database mapping system just in case the
   single Locator has changed and may no longer be reachable to
   accept the Map-Request.

So my point is that the attack is similar (true) but in some cases the 
amplification attack is through the Mapping System. Again the attack is 
bounded by the rate-limit set the xTR. In my view this should be also 
stated.


Regards

Albert



Editorial, please consider them suggestions, at the end it is a matter
of taste of the writer/reader.


ok, will take them into account according to other reviews.


 1.  Introduction

The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].

specified instead of defined?

The present document assesses the security level and identifies
security threats in the LISP specification if LISP is deployed 
in the

Internet (i.e., a public non-trustable environment).  As a result of
the performed analysis, the document discusses the severity of the
threats and proposes recommendations to reach the same level of
security in LISP than in Internet today (e.g., without LISP).

(i.e., without LISP) (not e.g.,) I understand that the authors are not
referring to an example.

This document does not consider all the possible uses of LISP as
discussed in [RFC6830].  The document focuses on LISP unicast,
including as well LISP Interworking [RFC6832], LISP-MS 
[RFC6833], and

LISP Map-Versioning [RFC6834].  The reading of these documents is a
prerequisite for understanding the present document.

Several deployment scenarios are discussed in
draft-ietf-lisp-deployment, please consider citing it and discussing if
the use-cases described in the deployment draft are covered by this
analysis.

SA  is an off-path attacker that is able to send spoofed packets,
i.e., packets with a different source IP address than its
assigned IP address.  SA stands for Spoofing Attacker.

SA attackers need access to the RLOC space, it might make sense to state
this here.

 4.3.1.2.  Threats concerning Interworking

[RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow

Edit and instead of And

On 02/12/2013 3:02, Terry Manderson wrote:

I would just like to highlight that the end of this LC draws near.

Without review, this document cannot move forward.

Cheers
Terry

On 20/11/13 9:23 AM, Terry Mandersonterry.mander...@icann.org  wrote:


All,

As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have
requested a work group last call.

Here starts a 14 day last call for this document, the last call will end
on
Wednesday 4th December 2013.

You will find its text here:
http://tools.ietf.org/html/draft-ietf-lisp-threats-08

Please review this WG item and provide any last comments.

Cheers
Terry


___
lisp mailing list

Re: [lisp] WGLC draft-ietf-lisp-threats-08

[Albert Cabellos]

Hi

I went through the document in detail and IMHO it is well structured and
more importantly, it provides a complete and meticulous analysis of the
security threats of LISP on a public deployment.
Below you can find some comments:

Regards

Albert


* Section 4.2-In addition to the attacks described in this section
end-hosts behind an ITR could use the data-plane to overflow the ITR's
Map-Cache by sending packets to non-popular EID prefixes (pretty much as
a scan attack but with a different goal). In this scenario the xTR may
evict entries from the map-cache that are popular (and in-use) and 
disrupt the normal
operation of the network by forcing flows to miss. Florin will send a 
paper describing and analyzing

in detail the attack and its impact on cache performance.

* Section 4.3.2.1--RFC6830 states (referring to LSB):

These bits are used as
  a hint to convey up/down router status and not path reachability
  status.  The LSBs can be verified by use of one of the Locator
  reachability algorithms described inSection 6.3
http://tools.ietf.org/html/rfc6830#section-6.3.

To which extent this is a security threat? xTRs will not blindly trust LSB.


* Section 4.3.2.2-RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.


* Section 4.3.2.3-I´m having a hard time understanding this attack,
even under attack, the ETR will reply with the real nonce, at least
once. Probably I´m missing something.


* Section 4.4.1- In some cases the SMR-invoked Map-Request is sent
through the mapping system (not directly to the source RLOC), in this
case the attack is still effective and involves the Mapping System, the
Map-Server and the xTR (if operating in non-proxy mode).

Editorial, please consider them suggestions, at the end it is a matter
of taste of the writer/reader.

 1.  Introduction

The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].

specified instead of defined?

The present document assesses the security level and identifies
security threats in the LISP specification if LISP is deployed in the
Internet (i.e., a public non-trustable environment).  As a result of
the performed analysis, the document discusses the severity of the
threats and proposes recommendations to reach the same level of
security in LISP than in Internet today (e.g., without LISP).

(i.e., without LISP) (not e.g.,) I understand that the authors are not
referring to an example.

This document does not consider all the possible uses of LISP as
discussed in [RFC6830].  The document focuses on LISP unicast,
including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and
LISP Map-Versioning [RFC6834].  The reading of these documents is a
prerequisite for understanding the present document.

Several deployment scenarios are discussed in
draft-ietf-lisp-deployment, please consider citing it and discussing if
the use-cases described in the deployment draft are covered by this
analysis.

SA  is an off-path attacker that is able to send spoofed packets,
i.e., packets with a different source IP address than its
assigned IP address.  SA stands for Spoofing Attacker.

SA attackers need access to the RLOC space, it might make sense to state
this here.

 4.3.1.2.  Threats concerning Interworking

[RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow

Edit and instead of And

On 02/12/2013 3:02, Terry Manderson wrote:

I would just like to highlight that the end of this LC draws near.

Without review, this document cannot move forward.

Cheers
Terry

On 20/11/13 9:23 AM, Terry Manderson terry.mander...@icann.org wrote:


All,

As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have
requested a work group last call.

Here starts a 14 day last call for this document, the last call will end
on
Wednesday 4th December 2013.

You will find its text here:
http://tools.ietf.org/html/draft-ietf-lisp-threats-08

Please review this WG item and provide any last comments.

Cheers
Terry


___
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 support in Linux kernel?

[Albert Cabellos]

Hi

You might be interested in http://lispmob.org

This is a user-space linux implementation of LISP, we interface with the 
kernel through tun/tap and netlink. With this architecture we have a 
common code-base for linux, android and openwrt (embedded devices).


From our experience we have found that it is easier to support several 
platforms from the user-space. Pretty much any linux thing has netlink 
and tun/tap, so supporting a new platform should be straightforward, in 
most cases just re-compiling.


We actually used to have a data-plane lisp kernel module, the module is 
still public at the github lispmob repository.


Regards

Albert
On 07/11/2013 16:01, Rene Bartsch wrote:

Hi,

are there any ongoing attempts to integrate LISP into the network 
stack of the Linux-kernel?


That way we'd gain a foothold in most smartphones, tablets, embedded 
devices and Linux-servers/-desktops.




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)

[Albert Cabellos]

El 10/09/2013 10:30, Joel M. Halpern escribió:

Speaking personally, I have some concerns about this.

I think my concerns can be lumped into two related categories. Bother 
are about interoperability.


Firstly, I find the registration of LCAFs without any explanation of 
how or why they would be used to be awkward.  I know that some members 
of the WG like to have everything in one document.  But this is why we 
maintain registries.  Once we have defined LCAFs, it is quite sensible 
for documents which need LCAFs to add them to the registry, with the 
explanation of how and why the particular LCAF is beign defined.
Note that unlike base protocol mechanisms, the set of LCAFs is not 
something that all implementations need to understand.  A LISP 
implementation that is never going to do 5-tuple lookup does not need 
to know about LCAFs that are designed to handle that.  And conversely 
defining new LCAFs ought in my view create an obligation for new 
behavior in all LISP devices.  (I don't think the authors intend that 
kind of obligation.)




This is precisely the reason to standardize a flexible LCAF, there is no 
obligation to implement all the LCAFs defined, but just the ones that 
are used by a particular ITR. Pretty much like XML and the XML applications.
On a related note, I find very general LCAFs a cause for concern. 
Particular the JSON LCAF, which seems to allow the mapping system to 
reprogram the packet processing hardware on the fly seems excessive.  
I understand it is neat for experimentation.  But how does something 
injecting a JSON LCAF have a reasonable judgment about whether the ITR 
which will receive it will be able to implement the processing required?


Beyond the LCAF type, we can include a fixed size type that will tell 
the ITR if it is able to implement the processing required. From there 
we can define types that can be only used intra-domain or that are 
maningful inter-domain, again like XML applications.


If we are assuming particular deployment models, we need to describe 
that.  (Which leads to the question as to why it is in this document.)


Fully agree with this, two of the main reasons are flexiblity and to 
reduce the deployment cost of new applications of LISP. With the 
flexible LCAF we only need to update the ITR, not the mapping system. 
This is an important barrier for experimentation or new uses right now. 
Otherwise and as you mention, we will have to face and endless amount of 
LCAF types, one for each LISP use.


Regards

Albert


I may be in the rough on these concerns.

Yours,
Joel

On 9/10/13 12:35 AM, Dino Farinacci wrote:
Folks, I compiled all the input I received for updates to the LCAF 
draft. Find enclosed the updated draft and a diff file.


Deadline is tomorrow but we can have discussion before I post. So if 
there are any changes or comments, I can add them into the -03 draft. 
So I am not that worried about missing the deadline.


Changes include:

B.1.  Changes to draft-ietf-lisp-lcaf-03.txt

o  Submitted September 2013.

o  Updated references and author's affliations.

o  Added Instance-ID to the Multicast Info Type so there is relative
   ease in parsing (S,G) entries within a VPN.

o  Add port range encodings to the Application Data LCAF Type.

o  Add a new JSON LCAF Type.

o  Add Address Key/Value LCAF Type to allow attributes to be 
attached

   to an address.

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

Re: [lisp] Need comments on LISP Threats Analysis

[Albert Cabellos]

I agree that having a fixed cache-size can always result in an overflow, even 
from legitimate traffic.

Then IMHO we should try to answer two questions:

1) What is legitimate traffic? If any node behind an xTR is legitimate to 
generate traffic and hence, trigger Map-Requests, then we should stick to the 
best-effort policy, and when the limited cache-size is overflown drop entries 
in the map-cache. In this context we have published a paper than analyzes the 
hit rate vs. the cache-size considering internet-like traffic.

http://personals.ac.upc.edu/acabello/Albert_Cabellos/Publications_files/LISP%20Cache.pdf

2) How can we mitigate such attacks? For this, there is a huge amount of 
literature dealing with cache eviction policies. Besides that, we are also 
preparing a study on this, for the specific case of LISP and considering 
Internet-like traffic, I´ll be happy to share it when it´s ready. However I 
agree that different solutions should be considered for different scenarios. 

Albert
 
On Mar 20, 2013, at 3:02 PM, Joel M. Halpern j...@joelhalpern.com wrote:

 Well, there are regular reports of folks taking down BGP sessions because 
 they exceed the number of prefixes they can handle.
 And LISP EIDs are more granular and varied than BGP prefixes usually are.
 So it does seem a reasonable question to ask how we will protect ourselves 
 against this sort of problem.
 
 It is true that a device with enough local memory for the whole mapping table 
 is, by definition, not subject to this kind of attack.  But it seems doubtful 
 that we can expect most ITRs or ETRs to have that much memory.
 
 One of my concerns with the categorization is that the various practices 
 needed to counter different threats are not inherently consistent.  or are 
 they always generally applicable.  (Some of them are just plain good advice.  
 Some of them are good advice for internet deployment.  Some are good advice 
 for VPN deployments.)   So will the reader be able to tell whether he is at 
 risk for a given attack, and what he should be doing for his problem space 
 while still keeping an effective and operable LISP infrastructure?
 
 Yours,
 Joel
 
 On 3/20/2013 2:55 PM, Dino Farinacci wrote:
 From: Ronald Bonica rbon...@juniper.net
 
 3) query the map cache for each packet. If no entry exists, discard the
 packet and query the map server
 
 If you choose Option 3, won't the victim ETR map cache overflow?
 
 We've been over this ground about 18 times, haven't we?
 
 Answer #5: Don't have a fixed-sized cache. Then it cannot overflow.
 
 Yep, you are right Noel.
 
 Just like the BGP RIB does not have a fixed-size cache. So what happens when 
 there is no memory for BGP, ditto for LISP. There is no magic here folks.
 
 Dino
 
 
 Noel
 ___
 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] Comments on lisp-architecture

[Albert Cabellos]

Hi Noel,

Thanks! Actually after reading your email and realizing that ELPs can also be 
EIDs I agree with the MPLS example, I feel that it is a good example of what 
LISP can be,

Albert

On Nov 3, 2012, at 9:22 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote:

 From: Albert Cabellos acabe...@ac.upc.edu
 
 Hi, thanks for the comments; I'll reply in detail later, but one thing that
 caught my eye quickly:
 
 MPLS- Although it is a good analogy, I don't think that MPLS is a good
 example given that with LISP we can't stack labels.
 
 ??? LISP does use 'stacked' encapsulations (e.g. for a mobile node moving to
 a LISP site)?
 
 And the mapping output could be an MPLS header with a 'pre-loaded' label
 stack (that's how you do source routing in a label-based system - I'm not
 sure if the existing MPLS stuff uses that capability, but eventually in
 Nimrod [which was the place that came up with the idea of label stacks, see
 RFC-1753] we realized that was how to minimize state setup, by 'pre-loading'
 the flow stack at the time the packet is created).
 
 So I'm not sure I understand this comment?
 
 
 In any case, I'm OK with using some other example - I just used MPLS because
 that's one that had been discussed, because there's a lot of MPLS-capable
 infrastructure already deployed. Did you have an alternative suggestion? I
 can't quickly come up with one that's as good as MPLS.
 
   Noel

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Comments on draft-introduction

[Albert Cabellos]

Hi,

Below are my comments on the introduction draft.

Thanks!

Albert

[snip]

This likely resulted not just from lack of insight, but also the fact
that extra mechanism is needed to support this separation (and in the

Typo, that *an* extra mechanism

early days there were no resources to spare), as well as the lack of
need for it in the smaller networks of the time.  (It is a truism of
system design that small systems can get away with doing two things
with one mechanism, in a way that usually will not work when the
system gets much larger.)
 
The ISO protocol architecture took steps in this direction [NSAP],
but to the Internet community the necessity of a clear separation was
definitively shown by Saltzer.  [RFC1498] Later work expanded on
Saltzer's, and tied his separation concepts into the fate-sharing
concepts of Clark.  [Clark], [Chiappa]
 
The separation of location and identity is a step which has recently
been identified by the IRTF as a critically necessary evolutionary
architectural step for the Internet.  However, it has taken some time
for this requirement to be generally accepted by the Internet
engineering community at large, although it seems that this may
finally be happening.
 
The LISP system for separation of location and identity resulted from
the discussions of this topic at the Amsterdam IAB Routing and
Addressing Workshop, which took place in October 2006.  [RFC4984]
 
A small group of like-minded personnel from various scattered
locations within Cisco, spontaneously formed immediately after that
workshop, to work on an idea that came out of informal discussions at
the workshop.  The first Internet-Draft on LISP appeared in January,
2007, along with a LISP mailing list at the IETF.  [LISP]
 
Trial implementations started at that time, with initial trial
deployments underway since June 2007; the results of early experience
have been fed back into the design in a continuous, ongoing process
over several years.  LISP at this point represents a moderately
mature system, having undergone a long organic series of changes and
updates.
 
LISP transitioned from an IRTF activity to an IETF WG in March 2009,
and after numerous revisions, the basic specifications moved to
becoming RFCs in 2012 (although work to expand and improve it
continues, and undoubtly will for a long time to come).
 
 2.  Deployment Philosophy
 
It may seem odd to cover 'deployment philosophy' at this point in
such a document.  However the deployment philosophy was a major
driver for much of the design (to some degree the architecture, and
to a very large measure, the engineering).  So, as such an important
motivator, it is very desirable for readers to have this material in
hand as they examine the design, so that design choices that may seem
questionable at first glance can be better understood.
 
Experience over the last several decades has shown that having a
viable 'deployment model' for a new design is absolutely key to the
success of that design.  A new design may be fantastic - but if it
can not or will not be successfully deployed (for whatever factors),
it is useless.  This absolute primacy of a viable deployment model is
what has lead to some painful compromises in the design.
 
The extreme focus on a viable deployment scheme is one of the
novelties of LISP.

There is an in-depth discussion about deployment scenarios in: 
http://tools.ietf.org/html/draft-ietf-lisp-deployment-05. I also suggest citing 
this draft.

 2.1.  Economics
 
The key factor in successful adoption, as shown by recent experience
in the Internet - and little appreciated to begin with, some decades
back - is economics: does the new design have benefits which outweigh
its costs.

Typo?: missing ?

More importantly, this balance needs to hold for early adopters -
because if they do not receive benefits to their adoption, the sphere
of earliest adopters will not expand, and it will never get to
widespread deployment.  One might have the world's best clean-slate
design, but if it does not have a deployment plan which is
economically feasible, it's just a mildly interesting piece of paper.
 
This is particularly true of architectural enhancements, which are
far less likely to be an addition which one can 'bolt onto the side'
of existing mechanisms, and often offer their greatest benefits only
when widely (or ubiquitously) deployed.
 
Maximizing the cost-benefit ratio obviously has two aspects.  First,
on the cost side, by making the design as inexpensive as possible,
which means in part making the deployment as easy as possible.
Second, on the benefit side, by providing many new capabilities,
which is best done not by loading the design up with lots of features
or 

Re: [lisp] LISP (re-)Charter discussion

[Albert Cabellos]

In my humble opinion we should discuss what is the charter of this WG,  
if someone in another WG uses/extends LISP for VPN or mobility is his/ 
her choice.  This should not prevent that this WG could also work on  
such applications, if there are enough volunteers.


Further, and as Terry points out, LISP is experimental and hence, any  
L2/L3 VPN extensions will (most likely) end up being also experimental.


Given that I support the initial wording:

“The LISP WG is chartered to work on the LISP base protocol and any  
item which directly impact LISP including any base protocol changes  
required to enable VPN and mobile topologies (precise operational  
definitions of these topologies should be left for IETF WGs focused on  
these technologies).”


Albert

On 02/12/2011, at 16:54, Yakov Rekhter wrote:


Terry,

After a receiving the suggestions from Yakov and John, emailing  
some ADs,

the draft charter is as follows:

Please review, and highlight any areas missed. I'd like to close  
this off by

next Friday (9th Dec), and pass to our AD.

The IAB's October 2006 Routing and Addressing Workshop (RFC 4984)
rekindled interest in scalable routing and addressing architectures  
for

the Internet. Among the many issues driving this renewed interest are
concerns about the scalability of the routing system and the  
impending

exhaustion of the IPv4 address space. Since the IAB workshop, several
proposals have emerged which attempt to address the concerns  
expressed

there and elsewhere. In general, these proposals are based on the
locator/identifier separation.

The basic idea behind the separation is that the Internet  
architecture
combines two functions, routing locators, (where you are attached  
to the

network) and identifiers (who you are) in one number space: The IP
address. Proponents of the separation architecture postulate that
splitting these functions apart will yield several advantages,  
including

improved scalability for the routing system. The separation aims to
decouple locators and identifiers, thus allowing for efficient
aggregation of the routing locator space and providing persistent
identifiers in the identifier space.

LISP supports the separation of the IPv4 and IPv6 address space
following a network-based map-and-encapsulate scheme (RFC 1955). In
LISP, both identifiers and locators are IP addresses. In LISP,
identifiers are composed of two parts: a global portion that  
uniquely

identifies a particular site and a local portion that identifies an
interface within a site. The local portion may be subdivided to
identify a particular network within the site. For a given  
identifier,
LISP maps the global portion of the identifier into a set of  
locators

that can be used by de-capsulation devices to reach the identified
interface; as a consequence a host would typically change identifiers
when it moves from one site to another or whenever it moves from one
subnet to another within an site. Typically, the same IP address will
not be used as an identifier
and locator in LISP.

LISP requires no changes to end-systems or to most routers. LISP aims
for an incrementally deployable protocol.

A number of approaches are being looked at in parallel in other
contexts. The IRTF RRG examined several proposals, some of which were
published as IRTF-track Experimental RFCs.

The LISP WG is chartered to work on the LISP base protocol and any  
items
which directly impact LISP including any base protocol changes  
required to

enable VPN and mobile topologies (precise operational definitions of
these topologies should be left for IETF WGs focused on these  
technologies).


With respect to chartering LISP WG to work on the LISP base protocol
changes required to enable VPN, if these changes have to do with
enabling L2 VPNs, then such work should be done in L2VPN WG. If
these changes have to do with enabling L3 VPN, then such work should
be done in L3VPN WG. In both of these cases the outcome of this work
could be reviewed by the LISP WG.

The same should apply to work on enaling mobile topoligies.

With this in mind I propose to replace the above sentence with the
following:

 The LISP WG is chartered to work on the LISP base protocol and any  
items
 which directly impact LISP and are related to using LISP for  
improving

 Internet routing scalability.

Yakov.


The working group will encourage and support interoperable LISP
implementations as well as defining requirements for alternate  
mapping
systems. The Working Group will also develop security profiles for  
LISP

and the various LISP mapping systems.

It is expected that the results of specifying, implementing, and  
testing
LISP will be fed to the general efforts at the IETF and IRTF (e.g.,  
the

Routing Research Group) that attempts to understand which type of a
solution is optimal. The LISP WG is NOT chartered to develop the  
final

or standard solution for solving the routing scalability problem. Its
specifications are Experimental 

Re: [lisp] LISP (re-)Charter discussion

[Albert Cabellos]

Hi,

On 27/10/2011 7:10, Terry Manderson wrote:

WG hat on.

This follow-up is initiated due to a recent observation gleaned from a
presentation request for the Taipei meeting.

While this draft charter does not preclude taking on work items specifically
related to LISP VPN or LISP mobility, I think it's useful to tease out the
questions and put them to the WG for discussion.

Should LISP mobility be specifically included in the work plan?



I would like to point out that we have a small but growing community of 
people interested into LISPmob, we open-sourced the code 1.5 months ago.


Albert


Should LISP VPN modalities be specifically included in the work plan?

Cheers
Terry

On 20/10/11 9:23 AM, Terry Mandersonterry.mander...@icann.org  wrote:


Hi All,

Joel and I bounced the following charter around and have also passed it in
front of AD's eyes.

You obviously have time to chew on this for a while before Taipei.

The IAB's October 2006 Routing and Addressing Workshop (RFC 4984)
rekindled interest in scalable routing and addressing architectures for
the Internet. Among the many issues driving this renewed interest are
concerns about the scalability of the routing system and the impending
exhaustion of the IPv4 address space. Since the IAB workshop, several
proposals have emerged which attempt to address the concerns expressed
there and elsewhere. In general, these proposals are based on the
locator/identifier separation.

The basic idea behind the separation is that the Internet architecture
combines two functions, routing locators, (where you are attached to the
network) and identifiers (who you are) in one number space: The IP
address. Proponents of the separation architecture postulate that
splitting these functions apart will yield several advantages, including
improved scalability for the routing system. The separation aims to
decouple locators and identifiers, thus allowing for efficient
aggregation of the routing locator space and providing persistent
identifiers in the identifier space.

LISP supports the separation of the IPv4 and IPv6 address space
following a network-based map-and-encapsulate scheme (RFC 1955). In
LISP, both identifiers and locators are IP addresses. In LISP,
identifiers are composed of two parts: a global portion that uniquely
identifies a particular site and a local portion that identifies an
interface within a site. The local portion may be subdivided to
identify a particular network within the site. For a given identifier,
LISP maps the global portion of the identifier into a set of locators
that can be used by de-capsulation devices to reach the identified
interface; as a consequence a host would typically change identifiers
when it moves from one site to another or whenever it moves from one
subnet to another within an site. Typically, the same IP address will
not be used as an identifier
and locator in LISP.

LISP requires no changes to end-systems or to most routers. LISP aims
for an incrementally deployable protocol.

A number of approaches are being looked at in parallel in other
contexts. The IRTF RRG examined several proposals, some of which were
published as IRTF-track Experimental RFCs.

The LISP WG is chartered to work on the LISP base protocol and any items
which directly impact LISP. The working group will encourage and
support interoperable LISP implementations as well as defining
requirements for alternate mapping systems. The Working Group will also
develop security profiles for LISP and the various LISP mapping systems.

It is expected that the results of specifying, implementing, and testing
LISP will be fed to the general efforts at the IETF and IRTF (e.g., the
Routing Research Group) that attempts to understand which type of a
solution is optimal. The LISP WG is NOT chartered to develop the final
or standard solution for solving the routing scalability problem. Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic. In addition, as these issues are understood, the
working group will analyze and document the implications of LISP on
Internet traffic, applications, routers, and security. This analysis
will explain what role LISP can play in scalable routing. The analysis
should also look at scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on as well as the
manageability and operability of LISP.


Goals and Milestones

Jun 2012Forward draft-ietf-lisp-mib to the IESG.
Jun 2012Forward draft-ietf-lisp-sec to the IESG.
Jun 2012Forward draft-ietf-lisp-deployment to the IESG.
Jun 2012Forward a security proposal document (draft-ietf-lisp-threats)
 to the IESG.

Dec 2013Forward to the IESG an operational set of documents which should
 include cache management and ETR synchronization
 techniques inclusive of a cache management specification.

Jun 2014Forward