Subject: [lisp] Fwd: Expiration impending: <draft-ietf-lisp-lcaf-02.txt>

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Sep 2013 09:08:17 -0700

I have some updates that I will post to the list but if anyone thinks there are pending changes and you have told or requested of me to add text, can you please repost in this list so the entire working group can see the request and be part of the discussion. 

Thanks,
Dino

Begin forwarded message:

> From: IETF Secretariat <[email-masked]>
> Date: September 2, 2013 at 4:42:06 AM PDT
> To: "Dino Farinacci" <[email-masked]>, "David Meyer" <[email-masked]>, "Job Snijders" <[email-masked]>
> Cc: "Terry Manderson" <[email-masked]>, "Joel M. Halpern" <[email-masked]>
> Subject: Expiration impending: <draft-ietf-lisp-lcaf-02.txt>
> 
> The following draft will expire soon:
> 
> Name:     draft-ietf-lisp-lcaf
> Title:    LISP Canonical Address Format (LCAF)
> State:    I-D Exists
> Expires:  2013-09-11 (in 1 week, 1 day)
>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 2 Sep 2013 19:21:34 +0200

Dear Dino, all,

Here are some ideas we have for new types of LCAFs.

First, we will like to see a 5-tuple LCAF to allow mapping lookups based on
flows. In the attached TXT there is a proposed format. It allows to perform
exact match flow lookups, as well as best match lookups using port range
and prefix mask length. The proposed 5-tuple LCAF is based on current types
4 and 12, and can be a new type itself, or be merged with those types.

Second, we find interesting to have a generic (self-defined) LCAF type. A
format like that will allow complex and/or experimental LISP applications.
We aim for a binary JSON-like format. This LCAF type almost needs no
definition, just a new LCAF type number and an agreement on the binary
specification to use. Personally, I like the Universal Binary JSON
Specification (http://ubjson.org/).

I would like to know what the WG thinks of these proposals.

Thanks,
Alberto

On 2 September 2013 18:08, Dino Farinacci <[email-masked]> wrote:

> I have some updates that I will post to the list but if anyone thinks
> there are pending changes and you have told or requested of me to add text,
> can you please repost in this list so the entire working group can see the
> request and be part of the discussion.
>
> Thanks,
> Dino
>
>
> Begin forwarded message:
>
> *From:* IETF Secretariat <[email-masked]>
> *Date:* September 2, 2013 at 4:42:06 AM PDT
> *To:* "Dino Farinacci" <[email-masked]>, "David Meyer" <[email-masked]>,
> "Job Snijders" <[email-masked]>
> *Cc:* "Terry Manderson" <[email-masked]>, "Joel M. Halpern" <
> [email-masked]>
> *Subject:* *Expiration impending: <draft-ietf-lisp-lcaf-02.txt>*
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 02 Sep 2013 13:32:59 -0400

With regard to the generic LCAF, it seems that each usage would have to 
specify what it was actually going to use it for, but this would not be 
captured in the mapping system.
This would seem to lead to the situation where one entity is looking 
things up with one purpose in mind, but finds mapping for some other 
purpose, which it can not support.

Yours,
Joel

On 9/2/13 1:21 PM, Alberto Rodriguez-Natal wrote:
> First, we will like to see a 5-tuple LCAF to allow mapping lookups based
> on flows. In the attached TXT there is a proposed format. It allows to
> perform exact match flow lookups, as well as best match lookups using
> port range and prefix mask length. The proposed 5-tuple LCAF is based on
> current types 4 and 12, and can be a new type itself, or be merged with
> those types.
>
> Second, we find interesting to have a generic (self-defined) LCAF type.
> A format like that will allow complex and/or experimental LISP
> applications. We aim for a binary JSON-like format. This LCAF type
> almost needs no definition, just a new LCAF type number and an agreement
> on the binary specification to use. Personally, I like the Universal
> Binary JSON Specification (http://ubjson.org/).
>
> On 2 September 2013 18:08, Dino Farinacci <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I have some updates that I will post to the list but if anyone
>     thinks there are pending changes and you have told or requested of
>     me to add text, can you please repost in this list so the entire
>     working group can see the request and be part of the discussion.
>
>     Thanks,
>     Dino
>
>
>     Begin forwarded message:
>
>>     *From:* IETF Secretariat <[email-masked]
>>     <mailto:[email-masked]>>
>>     *To:* "Dino Farinacci" <[email-masked]
>>     <mailto:[email-masked]>>, "David Meyer" <[email-masked]
>>     <mailto:[email-masked]>>, "Job Snijders" <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc:* "Terry Manderson" <[email-masked]
>>     <mailto:[email-masked]>>, "Joel M. Halpern"
>>     <[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 4 Sep 2013 15:18:06 +0200

Joel,

The idea we have in mind for this generic LCAF is intradomain deployments
where the same entity (or several entities with some sort of agreement) has
control over both MS/MR and xTR/RTR devices. In that scenario the exact
usage of the generic encoding will be arrange in advance.

The value we see on the generic LCAF is that it allows the deployment of
new applications without need to modify the mapping system. If an entity
has a fresh idea involving LISP, and it has LISP devices that support a
generic LCAF encoding, it can deploy its idea immediately. This a way to
encourage the experimentation and innovation with LISP.

For the scenario you propose (no beforehand agreement between entities), we
can introduce some kind of "sub-type" to specify the exact purpose of the
generic LCAF. This "sub-type" can be encoded as the very first field on the
generic part.

Let me know what you think.

Alberto

On 2 September 2013 19:32, Joel M. Halpern <[email-masked]> wrote:

>>      *From:* IETF Secretariat <ietf-secretariat-reply@ietf.**org<[email-masked]>
>>>     <mailto:[email-masked]<[email-masked]>
>>> >>
>>>     <mailto:terry.manderson@icann.**org <[email-masked]>>>,
>>> "Joel M. Halpern"
>>     ______________________________**_________________
>>     lisp mailing list
>>     https://www.ietf.org/mailman/**listinfo/lisp<https://www.ietf.org/mailman/listinfo/lisp>
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> lisp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/lisp<https://www.ietf.org/mailman/listinfo/lisp>
>>
>>

---

From: Edward Lopez <[email-masked]>
Date: Wed, 4 Sep 2013 16:25:34 +0000

I concur with Alberto in that we need to consider an intradomain deployment scenario.  For example, suppose I have a stateful firewall and a variety of content inspection engines that are LISP-enabled.  It would be desirable to have the firewall as an action LISP encapsulate traffic-of-interest and forward it to the appropriate content inspection engine for deeper inspection.  A definable LCAF would be very useful in this case, and I like the idea of using a JSON-like format

Currently such scenarios are only feasible with a combination of policy-based routing and VPN/GRE tunneling to establish one-hop adjacencies.  An intradomain LISP model could be used to develop highly resilient, centralized content/application solutions

Ed Lopez

On Sep 4, 2013, at 9:18 AM, Alberto Rodriguez-Natal <[email-masked]<mailto:[email-masked]>> wrote:

Joel,

The idea we have in mind for this generic LCAF is intradomain deployments where the same entity (or several entities with some sort of agreement) has control over both MS/MR and xTR/RTR devices. In that scenario the exact usage of the generic encoding will be arrange in advance.

The value we see on the generic LCAF is that it allows the deployment of new applications without need to modify the mapping system. If an entity has a fresh idea involving LISP, and it has LISP devices that support a generic LCAF encoding, it can deploy its idea immediately. This a way to encourage the experimentation and innovation with LISP.

For the scenario you propose (no beforehand agreement between entities), we can introduce some kind of "sub-type" to specify the exact purpose of the generic LCAF. This "sub-type" can be encoded as the very first field on the generic part.

Alberto

On 2 September 2013 19:32, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
With regard to the generic LCAF, it seems that each usage would have to specify what it was actually going to use it for, but this would not be captured in the mapping system.
This would seem to lead to the situation where one entity is looking things up with one purpose in mind, but finds mapping for some other purpose, which it can not support.

Yours,
Joel

Thanks,
Alberto

On 2 September 2013 18:08, Dino Farinacci <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Thanks,
    Dino

    Begin forwarded message:

    *From:* IETF Secretariat <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>
    *Date:* September 2, 2013 at 4:42:06 AM PDT
    *To:* "Dino Farinacci" <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>, "David Meyer" <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>, "Job Snijders" <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>
    *Cc:* "Terry Manderson" <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>, "Joel M. Halpern"
    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
    *Subject:* *Expiration impending: <draft-ietf-lisp-lcaf-02.txt>*

    _______________________________________________
    lisp mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Sep 2013 20:07:16 -0700

> First, we will like to see a 5-tuple LCAF to allow mapping lookups based on flows. In the attached TXT there is a proposed format. It allows to perform exact match flow lookups, as well as best match lookups using port range and prefix mask length. The proposed 5-tuple LCAF is based on current types 4 and 12, and can be a new type itself, or be merged with those types.

At the risk of adding too many new LCAFs with too many combinations, this is what I propose.

(1) Change Type 4 to include port ranges.
(2) Use Type 4 and Type 12 together in a AFI-List type.

That should serve all purposes.

> Second, we find interesting to have a generic (self-defined) LCAF type. A format like that will allow complex and/or experimental LISP applications. We aim for a binary JSON-like format. This LCAF type almost needs no definition, just a new LCAF type number and an agreement on the binary specification to use. Personally, I like the Universal Binary JSON Specification (http://ubjson.org/).

I think we should call it the JSON LCAF type so an EID or RLOC encoding is known to be JSON tuples. But I think they way this will be used is to use a regularly encoded EID and what is returned is a JSON encoded RLOC.

Also, I am not sure that binary coding is required. I can imagine some people wanting a XML encoding as well. And that would be in ascii or unicode.

I will propose text and the working group can comment on the text.

Dino