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

[Edward Lopez <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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.

Let me know what you think.

Alberto



On 2 September 2013 19:32, Joel M. Halpern <[e-mail]<mailto:[e-mail]>> 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


On 9/2/13 1:21 PM, Alberto Rodriguez-Natal wrote:
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 <[e-mail]<mailto:[e-mail]>
<mailto:[e-mail]<mailto:[e-mail]>>> 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 <[e-mail]<mailto:[e-mail]>
    <mailto:[e-mail]<mailto:[e-mail]>>>
    *Date:* September 2, 2013 at 4:42:06 AM PDT
    *To:* "Dino Farinacci" <[e-mail]<mailto:[e-mail]>
    <mailto:[e-mail]<mailto:[e-mail]>>>, "David Meyer" <[e-mail]<mailto:[e-mail]>
    <mailto:[e-mail]<mailto:[e-mail]>>>, "Job Snijders" <[e-mail]<mailto:[e-mail]>
    <mailto:[e-mail]<mailto:[e-mail]>>>
    *Cc:* "Terry Manderson" <[e-mail]<mailto:[e-mail]>
    <mailto:[e-mail]<mailto:[e-mail]>>>, "Joel M. Halpern"
    <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
    *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)


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





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


_______________________________________________
lisp mailing list
[e-mail]<mailto:[e-mail]>
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. ***