Subject: [lisp] draft charter for a LISP BOF/WG -- please comment

From: David Meyer <[email-masked]>
Date: Fri, 16 Jan 2009 09:44:12 -0800

We're looking at doing a WG forming BOF at the next IETF
	meeting, and the below is a draft of what such a WG
	charter would look like. 

	Comments please.

	Thnx,

	Dave

LISP (Locator/ID Separation Protocol)

Last Modified: 2009-01-16

Chair(s):
 TBD

Internet Area Director(s):
 TBD

Routing Area Advisor:
 TBD

Secretary(ies):
 TBD
 
Mailing Lists:
 General Discussion: [email-masked]

Description of Working Group:

LISP and companion documents (see below) are proposals that
respond to the problems discussed at the IAB's October, 2006
Routing and Addressing Workshop [0]. The purpose of the BOF is to
form a working group whose charter (see below) is to work on the
design on the LISP base protocol [1], the LISP+ALT mapping system
[2], LISP Interworking [4] and LISP multicast [6]. The working
group will encourage and support interoperable LISP
implementations as well as defining requirements for alternate
mapping systems.

Goals and Milestones:

Mar 2010  Submit base LISP specification to the IESG for
          Experimental.

Mar 2010  Submit base ALT specification to the IESG for
          Experimental.

Mar 2010  Submit the LISP Interworking specification to the IESG
	  for Experimental.

Mar 2010  Re-charter or close.

Internet-Drafts:
	draft-farinacci-lisp-11.txt
	draft-farinacci-lisp-multicast-00.txt
	draft-fuller-lisp-alt-03.txt
	draft-lewis-lisp-interworking-02.txt

Request For Comments:
	  None

References
----------
[0]     Meyer, D. et. al., "Report from the IAB Workshop on
        Routing and Addressing", RFC 4984.

[1]     Farinacci, D. et. al., "Locator/ID Separation Protocol
        (LISP)", draft-farinacci-lisp-11.txt.

[2]	Fuller, V., et. al., "LISP Alternative Topology
	(LISP-ALT)", draft-fuller-lisp-alt-03.txt

[3]	Iannone, L., and O. Bonaventure, "OpenLISP Implementation
	Report", draft-iannone-openlisp-implementation-01.txt.

[4]	Lewis, D., et. al., "Interworking LISP with IPv4 and
	IPv6", draft-lewis-lisp-interworking-02.txt.

[5]	Mathy, L., et. al., "LISP-DHT: Towards a DHT to map
	identifiers onto locators", draft-mathy-lisp-dht-00.txt.

[6]     Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
	"LISP for Multicast Environments",
	draft-farinacci-lisp-multicast-00.txt.  
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Scott Brim <[email-masked]>
Date: Fri, 16 Jan 2009 16:17:31 -0500

Hi Dave.  Multicast is listed as a draft to work on but is not in the
milestonesm, even though all the others are.

---

From: Olivier Bonaventure <[email-masked]>
Date: Sat, 17 Jan 2009 11:43:13 +0100

Dave,

> Mar 2010  Submit base ALT specification to the IESG for

Although ALT is the first deployed mapping proposal, I don't think that
a LISP working group should only consider this approach. I think that
the WG should work on Mapping systems in general and ALT could be one of
the solutions, but I would not restrict this in the description.

Olivier
-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: David Meyer <[email-masked]>
Date: Sun, 18 Jan 2009 12:25:42 -0800

Oliver,

> the solutions, but I would not restrict this in the description.

	Well taken. I'll modify the text to reflect that.

	Dave

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 18 Jan 2009 23:28:41 +0100

Dave,
> 	meeting, and the below is a draft of what such a WG

Another point that should be discussed in a LISP WG is how locators and
EIDs should be allocated. This is more a policy than a protocol issue,
but I think that it will have an impact on the long-term scalablity of a
solution such as LISP.

Concerning the allocation of the EIDs, the issues to be discussed are at
least the following :
- size of an EID allocation
- lifetime of an EID allocation

Concerning the locators, an important requirement for the scalability of
the underlying routing system is that it should be possible to allocate
locators in a way that follows the network topology. In practice, this
implies that locators will have a limited lifetime and that all xTR (and
the supporting services including the mapping system) should be prepared
 for a change of their locator. Locator renumbering should be part of
the standardised solution from day one. Otherwise, we'll be stuck in the
same situation as with IPv6 today where renumbering is still not solved
and network operators are changing the policies of the RIRs to ensure
that they will not need to renumber.

Olivier

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Jan 2009 20:10:52 -0800

> but I think that it will have an impact on the long-term scalablity  

So, do you think the working group should have in it's charter to work  
on both protocols and operational practices?

> that they will not need to renumber.

Definitely agree.

Dino

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 19 Jan 2009 09:03:36 +0100

Dino,

> on both protocols and operational practices?

Usually, protocols and operational practices are decoupled as we need
some time to learn from the actual deployment to document operationnal
practices. However, in the case of LISP, if the objective is a set of
Experimental RFCs, then having experimental operationnal practices that
are documented would be useful. This might be done by asking IANA for a
small reserved block of addresses to be used as EIDs for a limited time
and the establishment of an experimental registry (e.g. within an
existing RIR willing to experiment) to also evaluate this part of the
solution.

Olivier

---

From: David Meyer <[email-masked]>
Date: Mon, 19 Jan 2009 08:43:02 -0800

> that they will not need to renumber.

	Agree. I'll also add that.

	Dave

---

From: Scott Brim <[email-masked]>
Date: Mon, 19 Jan 2009 11:52:47 -0500

Excerpts from Olivier Bonaventure on Sun, Jan 18, 2009 11:28:41PM
+0100:
> Concerning the locators, an important requirement for the
> scalability of the underlying routing system is that it should be
> possible to allocate locators in a way that follows the network
> topology. In practice, this implies that locators will have a
> limited lifetime and that all xTR (and the supporting services
> including the mapping system) should be prepared for a change of
> their locator. Locator renumbering should be part of the
> standardised solution from day one. Otherwise, we'll be stuck in the
> same situation as with IPv6 today where renumbering is still not
> solved and network operators are changing the policies of the RIRs
> to ensure that they will not need to renumber.

When you say locators, I hope you mean the core-facing RLOCs.  
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: David Meyer <[email-masked]>
Date: Mon, 19 Jan 2009 08:54:26 -0800

> existing RIR willing to experiment) to also evaluate this part of the

	As you may (or may not) know, we do have both IPv4 and
	IPv6 EID prefixes in use now (153.16/16 and
	2610:D0:/32). It would be great if an RIR would pick up
	allocation of their part of the address space. The
	current model has RIPE, ARIN, LACNIC (actually UY) at the
	top of the aggregation hierarchy, and each has a /20
	(from 153.16/16) and a /36 (2610:D0:/32). We're also
	working with folks at APNIC, and hope to have them going
	soon. So there is a kind of "square" at the top of the
	ALT hierarchy consisting of RIPE, ARIN, APNIC, and
	LACNIC. 

	So much of this is built (at least on the scale we could
	with a /16, for example). What you suggest that isn't
	done is that no RIR has picked up allocating this
	space. So I agree it would be a very good thing if one or
	more of the RIRs would pick up allocating these (that is
	exactly the kind of experience we'd like to get).

	That said, perhaps the charter should include a work item
	that looks something like "guidelines for allocating IPv4
	and IPv6 EID prefixes" or something similar. What do
	folks think?

	Dave

---

From: Scott Brim <[email-masked]>
Date: Mon, 19 Jan 2009 11:54:54 -0500

> existing RIR willing to experiment) to also evaluate this part of the

I am hesitant to mix this all together.  Of course we need an
allocation scheme for the experiment to go forward, but that is not
the same as deciding how things will be allocated in production.
There is a lot of politics there.  I would say that all we need is an
existence proof that there is a way to allocate EIDs and RLOCs, but we
don't need to come up with a recommendation on what the Internet /
RIRs should do.  I hope.

Scott

---

From: David Meyer <[email-masked]>
Date: Mon, 19 Jan 2009 08:58:42 -0800

All,

> When you say locators, I hope you mean the core-facing RLOCs.  

	That is how I read it, and there are various proposals
	around for how to do this. 

	Do folks want to have an independent work item (i.e.,
	draft) for this, or do you envision that xTR renumbering
	be folded into the base spec?

	Dave

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Jan 2009 09:01:54 -0800

>> some time to learn from the actual deployment to document  

Yes, and we have a mix of success this way.

> I am hesitant to mix this all together.  Of course we need an

I think if we want to build practical solutions, we need the protocol  
designers to listen and work with the operational folks. And we need  
the operational folks help with designing the protocols. There are  
good minds that have the capability to "cross over".

I, personally, have done this in the past and practical solutions do  
result. In fact, we find out way early when we make mistakes.

> the same as deciding how things will be allocated in production.

Scott, let's at least get going with some model that is reasonable. We  
don't need to wait or delay or add more process if we don't have to.

> don't need to come up with a recommendation on what the Internet /

We need the entropy factor in this as well. So we need to deploy  
something so people understand how existing deployment models will  
change, if they change at all and if new deployment models and  
business opportunities develop.

Dino

---

From: Scott Brim <[email-masked]>
Date: Mon, 19 Jan 2009 12:02:59 -0500

Excerpts from David Meyer on Mon, Jan 19, 2009 08:58:42AM -0800:
> > > scalability of the underlying routing system is that it should
> > > be possible to allocate locators in a way that follows the
> > > network topology. In practice, this implies that locators will
> > > have a limited lifetime and that all xTR (and the supporting
> > > services including the mapping system) should be prepared for a
> > > change of their locator. Locator renumbering should be part of
> > > the standardised solution from day one. Otherwise, we'll be
> > > stuck in the same situation as with IPv6 today where renumbering
> > > is still not solved and network operators are changing the
> > > policies of the RIRs to ensure that they will not need to
> > > renumber.
> > 
> 	That is how I read it, and there are various proposals around
> 	for how to do this. 
> 
> 	Do folks want to have an independent work item (i.e., draft)
> 	for this, or do you envision that xTR renumbering be folded
> 	into the base spec?

It's not an extension.  Let's leave it in the base spec unless/until
the base spec gets too big.
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Scott Brim <[email-masked]>
Date: Mon, 19 Jan 2009 12:04:41 -0500

Excerpts from Dino Farinacci on Mon, Jan 19, 2009 09:01:54AM -0800:
> Scott, let's at least get going with some model that is reasonable. 

Yup - see "existence proof".  

> change, if they change at all and if new deployment models and business 
> opportunities develop.

Yes

---

From: David Meyer <[email-masked]>
Date: Mon, 19 Jan 2009 09:12:30 -0800

Scott,

> don't need to come up with a recommendation on what the Internet /

	I would guess that a draft that provided guidance to the
	RIRs around EID allocation would be a generally good
	thing. The question (which I think you're raising) is
	whether such a draft should be part of the LISP WG that
	we're discussing. 

	Now, an argument could be made that what we're discussing
	here is a protocol WG, and that the RIR EID allocation
	guidance draft is more of an operational (and as you
	point out, political) document. In addition, as you know
	RIR policy is for the most part formulated by the RIR
	constituents, not the IETF. That said, a document
	outlining what we have in mind with respect to
	EID-allocation and aggregation would seem to be useful,
	if for no other reason that the ideas would be
	documented.

	So let me ask again: Do folks think a document describing
	EID allocation strategy, targeted at the RIRs, would be a
	useful (and appropriate) document for a LISP WG to
	produce, noting that there may be other venues for such a
	document, e.g., GROW. Please chime in.

	FYI - I've included a schematic of the EID addressing plan
	that we're using today below.

	Thnx,

	Dave

---

#
#        Consolidated LISP Addressing Plan
#
#       For IPv6
#
#       OrgName:    Cisco Systems, Inc.
#       OrgID:      CISCOS-2
#       Address:    170 West Tasman Drive
#       City:       San Jose
#       StateProv:  CA
#       PostalCode: 95134
#       Country:    US
#       
#       NetRange:   2610:00D0:0000:0000:0000:0000:0000:0000 - 
#       2610:00D0:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
#       CIDR:       2610:00D0:0000:0000:0000:0000:0000:0000/32
#       NetName:    LISPV6
#       NetHandle:  NET6-2610-D0-1
#       Parent:     NET6-2610-1
#       NetType:    Direct Assignment
#       Comment:
#       RegDate:    2008-05-09
#       Updated:    2008-05-09
#       
#       RTechHandle: DMM65-ARIN
#       RTechName:   Meyer, David
#       RTechPhone:  +1-541-346-1747
#       RTechEmail:  [email-masked]
#       
#       OrgTechHandle: DN5-ORG-ARIN
#       OrgTechName:   Cisco Systems, Inc.
#       OrgTechPhone:  +1-408-527-9223
#       OrgTechEmail:  [email-masked]
#
#
#
#               2610:D0:/32 -- The universe
#
#                2610:D0:1000:/36
#                          ^
#                          |
#                        continent
#
#                2610:D0:1100:/40
#                           ^
#                           |
#                          Region
#
#                2610:D0:1100:/48
#                             --
#                           sites
#
#
#
#       David Meyer
#       [email-masked]
#       Tue May  6 07:58:53 2008
#
#       $Header: /home/dmm/lisp/configs/RCS/addressing.plan,v 1.76 2009/01/16 16:13:31 dmm Exp $
#

IPv4 EID Space
--------------
NA:              153.16.0.0/20
EU:              153.16.32.0/20
Asia:            153.16.64.0/20
Africa:          153.16.96.0/20
Latin America:   153.16.128.0/20
Reserved:        153.16.160.0/20
                 153.16.192.0/20
                 153.16.224.0/20

IPv6 EID Space
--------------
NA:              2610:D0:1000::/36
EU:              2610:D0:2000::/36  
Asia:            2610:D0:3000::/36  
Africa:          2610:D0:4000::/36
Latin America:   2610:D0:5000::/36
Reserved:        2610:D0:6000::/36 - 2610:D0:F000::/36

---

From: Eliot Lear <[email-masked]>
Date: Mon, 19 Jan 2009 18:16:03 +0100

> that they will not need to renumber.

Ok, but what does this mean?  The difficulty of renumbering is 
by-and-large the orders of magnitude of changes that need to occur on 
the host level.  A 60,000 device network today has to renumber, well, 
60,000 devices in a renumbering event.  Of course in LISP those would be 
EIDs, and so you wouldn't imagine renumbering them.  On the locator 
front, we're talking what?  1/2 dozen systems?  Maybe 32 max?  But 
perhaps you mean it should be possible to support mobility?  In which 
case you could have 60,000 mappings, all changing constantly.

Eliot

---

From: Scott Brim <[email-masked]>
Date: Mon, 19 Jan 2009 12:34:31 -0500

> 	document, e.g., GROW. Please chime in.

OK, here's a suggestion: as the protocols are being finalized,

  - be sure that ops people agree that possible allocation approaches
    are reasonable (so the protocol isn't decoupled from reality).  

  - add yet another draft which will be "implications" of the design.
    With respect to this particular issue, it would include
    implications for how EIDs and Locators are allocated.

??

Scott

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Jan 2009 11:00:33 -0800

>> scalability of
>> solved
> Ok, but what does this mean?  The difficulty of renumbering is by- 
> and-large the orders of magnitude of changes that need to occur on  
> the host level.  A 60,000 device network today has to renumber,  
> well, 60,000 devices in a renumbering event.  Of course in LISP  
> those would be EIDs, and so you wouldn't imagine renumbering them.   
> On the locator front, we're talking what?  1/2 dozen systems?  Maybe  
> 32 max?  But perhaps you mean it should be possible to support  
> mobility?  In which case you could have 60,000 mappings, all  
> changing constantly.

In most cases 2-4.

Dino

---

From: "Benson Schliesser" <[email-masked]>
Date: Mon, 19 Jan 2009 15:45:45 -0600

Dave-

In response to your question: Yes, I think that the WG should document
recommendations for allocation and routing of both EIDs and RLOCs.

LISP may have other uses, but routing and addressing scale is the primary
motivation for its development. The WG should capture all salient points on
how LISP is thought to address these issues, while acknowledging that
external groups will ultimately decide how it's deployed. The WG should
probably stop short of capturing operational topics such as best practices,
which might belong in a future LISP-Ops WG.

IMHO,
-Benson

On Jan 19, 2009 11:12 AM, "David Meyer" <[email-masked]> wrote:

       Scott,

> Excerpts from Olivier Bonaventure on Mon, Jan 19, 2009 09:03:36AM +0100: >
> >> Another point tha...

       Thnx,

       Dave

---

#
#       $Header: /home/dmm/lisp/configs/RCS/addressing.plan,v 1.76
2009/01/16 16:13:31 dmm Exp $
#

IPv4 EID Space
--------------
NA:              153.16.0.0/20
EU:              153.16.32.0/20
Asia:            153.16.64.0/20
Africa:          153.16.96.0/20

IPv6 EID Space
--------------
NA:              2610:D0:1000::/36
EU:              2610:D0:2000::/36
Asia:            2610:D0:3000::/36

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 20 Jan 2009 12:09:13 +0100

Dave,
> 	ALT hierarchy consisting of RIPE, ARIN, APNIC, and
...
> 	and IPv6 EID prefixes" or something similar. What do

I think that we should look at the type of information that needs to be
maintained and provided by an EID allocation authority.

If we would to be able to secure the mapping systems (and I'm convinced
that we'll have to), we'll likely need to have cryptographical
certificates that are provided by the allocation authority to the owner
of the EID block. These certificates could be similar to those that are
being discussed within the SIDR WG. They will allow EID block owners to
prove the ownership of their EID blocks. A successful LISP experiment
should also consider this problem.

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 20 Jan 2009 12:11:14 +0100

Dave,

Yes

> 	be folded into the base spec?

If RLOC renumbering is part of the base spec, then it will be
implemented by everyone and everybody will know that they need to plan
for a renumbering of their RLOCs. I would vote for discussing it in the
base spec unless it becomes too large.

Olivier

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Jan 2009 13:10:19 +0100

Olivier,
> base spec unless it becomes too large.

Let me restate my earlier screed: what is the frequency of the event?  
Let's consider three options:

Frequency of change
	Sort of Solution required
	Pluses / Minuses
Whenever you change provider (rare)
	Manual, management
	Very easy to implement; less infrastructure needed to maintain; but 
constrains the solution space.
Whenever you dial up your ppp connection
	automated management
	Provides more generality, plug and play for the house; but requires 
automated validation check for EID<->RLOC binding, but can be done 
through provisioning function
As you move from one location to another
	automated signaling/control plane
	Most general (DEBE - does everything but eat) solution, but high 
signaling overhead, introduces immediate potential for additional points 
of failure, RPA (royal pain in the ...)

I'd argue for sufficient architectural separation that you can do any or 
all three, but I would probably aim for (2) as a good initial target 
that is not too high not too low.

Regards,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Jan 2009 13:48:39 +0100

Let's try that one again with some formatting:

Frequency of Change

Sort of Solution Required

Pluses / Minuses

Manual management

Very easy to implement; less infrastructure
needed to maintain; but constrains the solution space.

Automated management

Provides more generality, plug and play for the
house; but requires automated validation check for EID<->RLOC
binding, but can be done through provisioning function.

(mobility)

Automated signaling/control plane

Most general (DEBE - does everything but eat)
solution, but high signaling overhead, introduces immediate potential
for additional points of failure, RPA (royal pain in the ...)

---

From: David Meyer <[email-masked]>
Date: Tue, 20 Jan 2009 08:00:38 -0800

> should also consider this problem.

	Right. The idea was to use whatever the SIDR WG came up
	with (I had mentioned this to Sandy in Dublin, and she
	didn't see any issue with that). In any event, no reason
	to reinvent the wheel. 

	Dave

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 20 Jan 2009 22:55:15 +0100

> Ok, but what does this mean? 

The situation that I have in mind is an xTR that serves one EID prefix.

This xTR is attached to one router of an ISP. The xTR receives its IP
address (V4 and/or v6) by using a protocol similar to DHCP that provides
an RLOC and a lifetime. Using such a protocol gives flexibility to the
ISP and allows it to renumber its network when needed for scalability
reasons.

When the xTR's RLOC needs to change, it should be able to use both the
oldRLOC and the newRLOC for some time, as with IPv6 today. Ideally, the
xTR should be able to update the mapping system autonomously, by sending
 something similar to the dynamic updates used by DNS.

> The difficulty of renumbering is
> EIDs, and so you wouldn't imagine renumbering them.  

Renumbering EIDs is outside the scope of LISP

Olivier