On 10/15/15 6:41 PM, Luigi Iannone wrote:
Hi Fabio,
On 14 Oct 2015, at 17:27, Fabio Maino <[email protected]> wrote:
On 10/14/15 1:23 AM, Luigi Iannone wrote:
Hi Fabio,
thanks for the feedback.
Are you saying that the scope of the proposed chart is too large?
No, I think the scope is very appropriate. I was just suggesting that we use
those two use cases to drive the design decisions.
There are clearly many more use cases that a LISP overlay can be used for, but
in my opinion those two are well understood and will help focusing the group on
the protocol work that you have identified. I selected those two, and
articulated them in that way, exactly because they can cover the whole scope of
the outlined work.
If we include those two use cases in the charter, probably it should also
mention that those are not the only ones, but are used to drive the design.
I kind of confused here. You agree that there is the right scope in the
proposed charter but that is lacking use-cases.
I would prefer having a charter that states what we are working on, not where
our work can/will be applied.
If people are interested in use-cases, it is possible to add a use-case
document where we document where the work can be used.
Would people be happy with such type of solution?
Sorry for getting to this only now, Luigi.
I am suggesting to use the two use cases as a way to drive/justify
requirements. I think they are well understood, and can provide a guide
for the WG to prioritize what to do first.
I don't want to limit LISP use to those two use cases only. Rather than
having a single document encompassing all use cases (that will never be
complete), I think it might be useful to allow the WG to adopt use cases
documents as guide to the extensions needed.
From what I see in your mail I would say that the proposed charter covers all
of your work items (with the exception of the programmatic northbound access to
the mapping).
Yes. I think the SDN angle is very important for an overlay, and may drive very
relevant components of the architecture. The text you posted does refers to
YANG modeling, that is one component of programmability, but I would like to
see this requirement more explicit, particularly for the mapping system.
I believe LISP, with the clean separation of the forwarding function provided
by the mapping system, can play a key role in controller-based SDN
applications. Again, it's not the only way to use LISP, but I think it's an
opportunity that the WG should pick up.
I would prefer that in the charter we refer only to IETF work. This means
avoiding acronyms like SDN. First because it is a I_R_TF work, second because
SDN way too large. It means different things for different people, so I am
unsure on whether it helps in defining a clear scope for our work.
Luigi, I have not used "SDN" in the actual wording I suggested for the
use cases. I referred to "programmatic northbound access to the mapping
and to xTR configuration", exactly to avoid to be too generic.
YANG is different, because it is clearly an IETF effort and is something that
we have anyway to consider.
Yet, you can always propose some text to help in give a better scope to the
proposed charter.
The second part of the sentence above provides motivation for YANG data
modeling of the xTR, the first part of the sentence helps understanding
why we may need pub/sub and other extensions to the protocol as
currently defined. Without specifying what we want to solve it's hard to
explain why we want to make some extensions to the protocol.
Thanks,
Fabio
ciao
L.
Thanks,
Fabio
Or I am misunderstanding your comment?
ciao
L.
On 13 Oct 2015, at 23:53, Fabio Maino <[email protected]> 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
might include Hierarchical Pull, Publish/Subscribe, or Push models
and related security extensions).
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
