Subject: [lisp] WG Charter

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 1 Jul 2015 10:18:14 -0400

One of the things Luigi and I as chairs would like to do in Prague is 
spend some time discussing among the WG participants what we want to 
work on going forward.  To enable this, we would like to start 
discussion on the list.  We will also follow the face to face with a 
summary to the list and further discussion.

There are two aspects that are related but distinct, so to start this 
off I want to identify them and ask folks to comment on them separately.

First, there is the question of direction for the basic LISP 
specification.  We can leave it as it is.  However, folks have asked us 
about moving it to Proposed Standard.  Based on our reading and 
discussion with relevant ADs, one path to do this would be to refocus 
the specification away from the core Internet scaling problems, and 
instead towards a scalable anxd flexible overlay technology.  This would 
not change the technical procedures, but would have significnat impact 
on the descriptive text.

Does the WG think this is a good idea?  If so, do folks want to do it?

Second, there are a large number of pieces that people have proposed 
(many with drafts).  There are probably too many to include everything 
in the charter.  Which things do people think are important for the WG. 
  In particular, explanations of why particular items are important, and 
comments pro or con from folks who are not the document authors are 
particularly useful to the community.  (I doubt that there will be 
significant negative comment since I have not seen proposals that are 
bad ideas.  However, the WG has to prioritize and choose.)

Yours,
Joel

---

From: Fabio Maino <[email-masked]>
Date: Wed, 01 Jul 2015 11:44:56 -0700

Joel, Luigi,
thanks for starting this conversation.

On 7/1/15 7:18 AM, Joel M. Halpern wrote:
> specification.  We can leave it as it is.  However, folks have asked 
> us about moving it to Proposed Standard.  Based on our reading and 
> instead towards a scalable anxd flexible overlay technology.  This 
> would not change the technical procedures, but would have significnat 
> impact on the descriptive text.
>

I think it is a good idea, and I would be willing to work to make it 
happen. In my experience with LISP deployments over the last few years, 
LISP has brought the most value to the table when used as a scalable, 
flexible, and (I would add to your list of attributes) programmable 
overlay technology.

I suspect this refocusing will make the life of the WG a little simpler, 
as the focus on core internet scaling problems has put the work done 
under a very tight scrutiny, some time making harder to evolve the 
protocol in the direction where a scalable overlay technology should go.

> in the charter.  Which things do people think are important for the 
> WG.  In particular, explanations of why particular items are 
> important, and comments pro or con from folks who are not the document 
> authors are particularly useful to the community.  (I doubt that there 
> will be significant negative comment since I have not seen proposals 
> that are bad ideas. However, the WG has to prioritize and choose.)
>

I agree, the new charter should help the WG focusing on LISP 
applications. As you note there have been quite a few proposals, but I 
think they can be summarized in a few areas (and relative use cases):
- LISP VPN (including integration with IPsec)
- NVO3 use case for DC virtualization (including support for VM mobility)
- SDN/NFV (including support for service chaining)
- IoT (LISP as connecting infrastructure for IoT applications)
- Mobile Node  (LISP-MN mobility)

I think the first 3 areas may drive an important change that, in my 
opinion, the WG should consider to include in the charter: how to 
support a multi-protocol encapsulation that allows integration with 
IPsec, support for L2 overlays, and support for explicit tagging and 
end-to-end metadata. With NVO3 selecting VXLAN-GPE as one of the 
supported encapsulations, and given the striking similarities with the 
LISP encap, I think the new drafts should be required to support both 
LISP and VXLAN-GPE encapsulations, as the LISP-GPE draft is trying to 
suggest.

There are a lot of common attributes for an overlay technology that 
works  across the areas described above. It's hard to make a priority, 
but probably the first 3 are the ones where the group can make quicker 
progress. It's also true that IoT and LISP-MN are probably the areas 
with the greatest potential. Rather than making the charter exclusive, I 
would try to leave the door open. We can use milestones to prioritize 
the initial focus, but at least the WG has a way to later add work in 
those areas.

Thanks,
Fabio

> Yours,
> Joel
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 01 Jul 2015 13:44:32 -0700

Fabio Maino wrote:
> end-to-end metadata.

Speaking only for myself as an individual:

+1 to Fabio's comment quoted above. This work would be complimentary to 
the work of several other WGs. And it's obvious to me that these 
applications of LISP technology are valuable for IETF to explore.

-Benson

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 1 Jul 2015 23:11:14 +0000

Hi Joel,

I will restate here what I said in the LISP WG meeting in Dallas when
you brought this up.

Since the recharter of NVO3 was made, it opened up other WGs to tailor
their protocols to meet the NVO3 control plane use cases/requirements.
The BESS WG has already made substantial progress in accommodating these
requirements as part of EVPN.

I believe that the scalability properties of the LISP protocols also have
promise to provide a very scalable solution to the NVO3 requirements.
Because of this, I would like to see the LISP WG recharter include the
NVO3 use cases.  Additionally, I can see LISP¹s flexibility useful for
enhancing basic Network Virtualization by serving as a control plane for
SFC as well, especially in conjunction with NVO3 overlays.

Thanks, Larry

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Jul 2015 09:06:27 -0700

> One of the things Luigi and I as chairs would like to do in Prague is spend some time discussing among the WG participants what we want to work on going forward.  To enable this, we would like to start discussion on the list.  We will also follow the face to face with a summary to the list and further discussion.

Great idea and a long time coming. Glad to hear.

> There are two aspects that are related but distinct, so to start this off I want to identify them and ask folks to comment on them separately.

I’ll add more to Fabio’s list when I respond in another email to his email.

> First, there is the question of direction for the basic LISP specification.  We can leave it as it is.  However, folks have asked us about moving it to Proposed Standard.  Based on our reading and discussion with relevant ADs, one path to do this would be to refocus the specification away from the core Internet scaling problems, and instead towards a scalable anxd flexible overlay technology.  This would not change the technical procedures, but would have significnat impact on the descriptive text.

This is fine but I am a bit worried we’ll spend time on “texting” and not creating anything new. We are way overdue in progressing use-case documents that people want to deploy, so I would like to make sure one work item doesn’t gate others. 

That is, I hope we can work in parallel. Where I do believe we WILL NOT lose focus.

> Does the WG think this is a good idea?  If so, do folks want to do it?

A very good idea IMO. But let’s not put creeping featurism into the exist RFC 6830, if that was your reference to “refocus the specification”. I assume you mean RFC 6830?

> Second, there are a large number of pieces that people have proposed (many with drafts).  There are probably too many to include everything in the charter.  Which things do people think are important for the WG.  In particular, explanations of why particular items are important, and comments pro or con from folks who are not the document authors are particularly useful to the community.  (I doubt that there will be significant negative comment since I have not seen proposals that are bad ideas.  However, the WG has to prioritize and choose.)

My experience with LISP (2 implementations and years of operation and deployment experience) that we can come down to a few protocol solutions that handle many use-cases. So the general IP address mobility use-case solves many other high-level use-cases.

That is VM-mobility and LISP Mobile-Node is the same solution it just a question if the EID and RLOC live in the same node (the former it does not but the latter it does).

I’ll respond to Fabio’s email with more details.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Jul 2015 09:23:57 -0700

> thanks for starting this conversation.

Yes, thanks for bringing up and providing leadership.

> I think it is a good idea, and I would be willing to work to make it happen. In my experience with LISP 

You can count me in to make major contributions or lead technical efforts.

> deployments over the last few years, LISP has brought the most value to the table when used as a scalable, flexible, and (I would add to your list of attributes) programmable overlay technology.

Yes, my experience shows this as well. In fact, the marketing value of LISP is its overlay capability and at the same time the core network is leaning with less state. This goes for unicast and multicast. So we could be thinking about all this in the reverse direction (but the requirements in 2007 was to save the routing table).

> I suspect this refocusing will make the life of the WG a little simpler, as the focus on core internet scaling problems has put the work done under a very tight scrutiny, some time making harder to evolve the protocol in the direction where a scalable overlay technology should go.

And I think we should encourage more users and operators to participate. I’ll help lobby up such organizations.

> I agree, the new charter should help the WG focusing on LISP applications. As you note there have been quite a few proposals, but I think they can be summarized in a few areas (and relative use cases):

This is really important and is a fall-out from what we already have. There is little machinery to be devleoped but focus needs attention on instance-ID assignment and if multiple mapping systems are used for intra-VPN and inter-VPN (regardless how many different ISPs are used for a given VPN for the underlay).

> - NVO3 use case for DC virtualization (including support for VM mobility)

Definitely. The working group has decided to go with both a push and pull control-plane. Bess is working on push ala BGP and there has been references time-and-time that the LISP mapping database could be used as the pull control-plane. Now is the time to formalize this.

> - SDN/NFV (including support for service chaining)

The LISP-TE draft supports this use-case and we have a couple of implemetnations that use the ELP LCAF to do service chaining.

> - IoT (LISP as connecting infrastructure for IoT applications)

Yes, for tracking sensors, for deciding if sensors should move, to provide access-control, etc.

> - Mobile Node  (LISP-MN mobility)

I think, as I said in the last email, we can combine “IP address mobility”, which means any type of address mobility (including MAC addressing and geo-coordinates as EID mobility) to be solved with one mechanism. Again, the question is if the RLOC and EID move together.

Others to add to the list:

- How overlays can be used to traffic-engineer underlays.
- How to simplify multicast when the underlay does not support multicast at all or partially.
- How mobility of EIDs, multicast, and data-plane security all work together.
- And most importantly with the advent of cloud applications (all that sit behind NATs) and residential service (homenet), work needs to be done with NAT-traversal. 

The last bullet is really important or you limit where you can deploy LISP. I have had a lot of implemetnation experience trying to get all the different LISP features to work across NATs. This includes and is not limited to RLOC-probing, lisp-crypto, multi-homing to multiple RTRs, xTRs behind multiple NATs and firewalls, and multicast.

> I think the first 3 areas may drive an important change that, in my opinion, the WG should consider to include in the charter: how to support a multi-protocol encapsulation that allows integration with IPsec, support for L2 overlays, and support for explicit tagging and end-to-end metadata. With NVO3 selecting VXLAN-GPE as one of the supported encapsulations, and given the striking similarities with the LISP encap, I think the new drafts should be required to support both LISP and VXLAN-GPE encapsulations, as the LISP-GPE draft is trying to suggest.

I think it is clear from the industry that the LISP control-plane can be used for multiple data-planes. So we should not limit or specify specifically (and not in one place) a single data-plane.

> There are a lot of common attributes for an overlay technology that works  across the areas described above. It's hard to make a priority, but probably the first 3 are the ones where the group can make 

I think we leave this for WG discussion. I don’t think anyone would argue with this following statement:

“An overlay needs to move unicast and multicast packets in a secure and scalable way in public and private addressing environments”.

That means:

(1) We need unicast and multicast EIDs. We need to support unicast and multicast RLOCs.
(2) We need to get VPNs to work when RLOCs and EIDs are private addresses and come from multiple address-families.
(3) We need the data-plane to provide privacy and control-plane to provide access-control and policy.
(4) And anything we do must scale. To what degree is debatable.

These are not new work items or changes to the LISP architecture. They are all supported and implemented in various forms in both open and close products.

> quicker progress. It's also true that IoT and LISP-MN are probably the areas with the greatest potential. Rather than making the charter exclusive, I would try to leave the door open. We can use milestones to prioritize the initial focus, but at least the WG has a way to later add work in those areas.

I think if we can have the charter describe items generally as categories, then a specific use-case as IoT or LISP-MN will just fit in one of those categories.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 2 Jul 2015 12:34:22 -0400

Just addressing one aspect here that strikes me as being helpful to the 
discussion.

On 7/2/15 12:06 PM, Dino Farinacci wrote:
...
>> specification.  We can leave it as it is.  However, folks have
>> asked us about moving it to Proposed Standard.  Based on our
>> reading and discussion with relevant ADs, one path to do this would
>> be to refocus the specification away from the core Internet scaling
>> problems, and instead towards a scalable anxd flexible overlay
>> technology.  This would not change the technical procedures, but
>> would have significnat impact on the descriptive text.
>
> This is fine but I am a bit worried we’ll spend time on “texting” and
> not creating anything new. We are way overdue in progressing use-case
> documents that people want to deploy, so I would like to make sure
> one work item doesn’t gate others.
>

The re-focusing of of 6830 will probably be almost exclusive 
word-smithing.  The intention is not to change the protocol behaviors at 
all.  We will likely remove text that is covered by the introduction and 
similarly remove text about solving the core scaling problem.    (Yes, 
spending energy on wording is annoying, unfortunate, and sometimes 
necessary.)

Since it is about the wording, not about changing any formats or 
procedures, I very much agree that this can and should go on in parallel 
with the work on addressing the technical topics we want to see covered.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Jul 2015 09:49:12 -0700

> 
> Just addressing one aspect here that strikes me as being helpful to the discussion.
> 
> The re-focusing of of 6830 will probably be almost exclusive word-smithing.  The intention is not to change the protocol behaviors at all.  We will likely remove text that is covered by the introduction and similarly remove text about solving the core scaling problem.    (Yes, spending energy on wording is annoying, unfortunate, and sometimes necessary.)

This is fine but one feature of an overlay is reducing routes in the core. So it is a feature that we’ll reduce routes in the core. If that is the same as solving “the core scaling problem”, is open for discussion. I agree the term “core scaling problem” is a very generic claim and very wide encompassing.

> Since it is about the wording, not about changing any formats or procedures, I very much agree that this can and should go on in parallel with the work on addressing the technical topics we want to see covered.

Agree.

Dino

---

From: Terry Manderson <[email-masked]>
Date: Fri, 3 Jul 2015 01:07:17 +0000

Regular participant hat on.

>Yes, thanks for bringing up and providing leadership.

+1 !!

>>happen. In my experience with LISP
>

Making the spec PS fits the envisaged evolution of the LISP "experiment".
The downside here might be that this is also recognition that LISP does
not fix the _global_ routing scalability issue (presuming of course that
the issue remains) in any short term exercise due to the way operators
actually choose to run BGP. Is the global internet ready and willing to
separate the locator and identifier in operations yet? I don't think so.

I would certainly say that it makes intra-AS routing systems leaner, as a
very positive outcome.

>
>> deployments over the last few years, LISP has brought the most value to
>>the table when used as a scalable, flexible, and (I would add to your
>>list of attributes) programmable overlay technology.
>
>Yes, my experience shows this as well. In fact, the marketing value of
>LISP is its overlay capability and at the same time the core network is
>leaning with less state. This goes for unicast and multicast. So we could
>be thinking about all this in the reverse direction (but the requirements
>in 2007 was to save the routing table).
>
>> I suspect this refocusing will make the life of the WG a little
>>simpler, as the focus on core internet scaling problems has put the work
>>done under a very tight scrutiny, some time making harder to evolve the

I think the scrutiny came through multiple different lenses. Not just
global routing scalability. I also doubt that the scrutiny will diminish.
But I do like the idea of calling it what it really is. It's an overlay
with attractive properties.

>
>These are not new work items or changes to the LISP architecture. They
>are all supported and implemented in various forms in both open and close
>products.
>
>> quicker progress. It's also true that IoT and LISP-MN are probably the
>>areas with the greatest potential. Rather than making the charter
>>exclusive, I would try to leave the door open. We can use milestones to
>>prioritize the initial focus, but at least the WG has a way to later add
>>work in those areas.
>
>I think if we can have the charter describe items generally as
>categories, then a specific use-case as IoT or LISP-MN will just fit in
>one of those categories.

Take care to not leave the door _wide_ open. I look at LISP as a very
(very!) well reviewed specification that currently is not overweight with
unused/unnecessary features. I have a concern that having all and sundry
adding in their pet feature may cause that attribute to suffer. Perhaps it
would be sane to pick the 4-5 priority items and work on those, nail them
and move forward that way.

Cheers
Terry

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 3 Jul 2015 07:37:31 +0000

Hi Dino,

> -----Original Message-----
> From: lisp [mailto:[email-masked]] On Behalf Of Dino Farinacci
> Sent: Friday, July 03, 2015 12:24 AM
> To: Fabio Maino
> Cc: LISP mailing list list
> Subject: Re: [lisp] WG Charter
> 
> > Joel, Luigi,
> >> One of the things Luigi and I as chairs would like to do in Prague is spend
> some time discussing among the WG participants what we want to work on
> going forward.  To enable this, we would like to start discussion on the list.
> We will also follow the face to face with a summary to the list and further
> discussion.
> >>
> >> There are two aspects that are related but distinct, so to start this off I want
> to identify them and ask folks to comment on them separately.
> >>
> >> First, there is the question of direction for the basic LISP specification.  We
> can leave it as it is.  However, folks have asked us about moving it to Proposed
> Standard.  Based on our reading and discussion with relevant ADs, one path to
> do this would be to refocus the specification away from the core Internet scaling
> problems, and instead towards a scalable anxd flexible overlay technology.
> This would not change the technical procedures, but would have significnat
> > deployments over the last few years, LISP has brought the most value to the
> table when used as a scalable, flexible, and (I would add to your list of attributes)
> programmable overlay technology.
> 
> Yes, my experience shows this as well. In fact, the marketing value of LISP is its
> overlay capability and at the same time the core network is leaning with less
> state. This goes for unicast and multicast. So we could be thinking about all this
> in the reverse direction (but the requirements in 2007 was to save the routing
> table).
> 
> > I suspect this refocusing will make the life of the WG a little simpler, as the
> focus on core internet scaling problems has put the work done under a very
> tight scrutiny, some time making harder to evolve the protocol in the direction
> where a scalable overlay technology should go.
> 
> >> Second, there are a large number of pieces that people have proposed (many
> with drafts).  There are probably too many to include everything in the charter.
> Which things do people think are important for the WG.  In particular,
> explanations of why particular items are important, and comments pro or con
> from folks who are not the document authors are particularly useful to the
> community.  (I doubt that there will be significant negative comment since I
> have not seen proposals that are bad ideas. However, the WG has to prioritize
> and choose.)
> >>
> >
> > I agree, the new charter should help the WG focusing on LISP applications. As
> you note there have been quite a few proposals, but I think they can be
> summarized in a few areas (and relative use cases):
> This is really important and is a fall-out from what we already have. There is little
> machinery to be devleoped but focus needs attention on instance-ID assignment
> and if multiple mapping systems are used for intra-VPN and inter-VPN
> (regardless how many different ISPs are used for a given VPN for the underlay).

As an alternative VPN technology, what's the major benefit of LISP VPN compared to MPLS/BGP IP VPN?

> Definitely. The working group has decided to go with both a push and pull
> control-plane. Bess is working on push ala BGP and there has been references
> time-and-time that the LISP mapping database could be used as the pull
> control-plane. Now is the time to formalize this.

From the data plane perspective, given the fact that there is unprecedented enthusiasm for defining various data plane encapsulations (e.g., VXLAN, NVGRE, VXLAN-GPE, GUE-NVO, GENEVE...) , it seems no surprise to add two more (e.g., LISP and LISP-GPE). From the control plane perspective, as BGP could be used as a pull-based control plane as well due to its prefix-ORF mechanism, what's the major advantage of LISP over BGP? 

> The LISP-TE draft supports this use-case and we have a couple of
> implemetnations that use the ELP LCAF to do service chaining.
> 
> I think, as I said in the last email, we can combine “IP address mobility”, which
> means any type of address mobility (including MAC addressing and
> geo-coordinates as EID mobility) to be solved with one mechanism. Again, the
> question is if the RLOC and EID move together.

Due to the new mobility requirements in 5G architecture (e.g., ultra-low latency), LISP-MN mobility may be a competitive candidate.

Best regards,
Xiaohu

> - And most importantly with the advent of cloud applications (all that sit behind
> NATs) and residential service (homenet), work needs to be done with
> NAT-traversal.
> 
> The last bullet is really important or you limit where you can deploy LISP. I have
> had a lot of implemetnation experience trying to get all the different LISP
> features to work across NATs. This includes and is not limited to RLOC-probing,
> lisp-crypto, multi-homing to multiple RTRs, xTRs behind multiple NATs and
> firewalls, and multicast.
> 
> > I think the first 3 areas may drive an important change that, in my opinion, the
> WG should consider to include in the charter: how to support a multi-protocol
> encapsulation that allows integration with IPsec, support for L2 overlays, and
> support for explicit tagging and end-to-end metadata. With NVO3 selecting
> VXLAN-GPE as one of the supported encapsulations, and given the striking
> similarities with the LISP encap, I think the new drafts should be required to
> support both LISP and VXLAN-GPE encapsulations, as the LISP-GPE draft is trying
> to suggest.
> 
> I think it is clear from the industry that the LISP control-plane can be used for
> multiple data-planes. So we should not limit or specify specifically (and not in
> one place) a single data-plane.
> 
> > There are a lot of common attributes for an overlay technology that works
> across the areas described above. It's hard to make a priority, but probably the
> first 3 are the ones where the group can make
> 
> “An overlay needs to move unicast and multicast packets in a secure and
> scalable way in public and private addressing environments”.
> 
> That means:
> 
> These are not new work items or changes to the LISP architecture. They are all
> supported and implemented in various forms in both open and close products.
> 
> > quicker progress. It's also true that IoT and LISP-MN are probably the areas
> with the greatest potential. Rather than making the charter exclusive, I would try
> to leave the door open. We can use milestones to prioritize the initial focus, but
> at least the WG has a way to later add work in those areas.
> 
> I think if we can have the charter describe items generally as categories, then a
> specific use-case as IoT or LISP-MN will just fit in one of those categories.
> 
> Dino
> 
> >
> > Thanks,
> > Fabio
> >
> >
> >
> >> Yours,
> >> Joel
> >>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Jul 2015 10:08:37 -0700

> separate the locator and identifier in operations yet? I don't think so.

I think it does fix the problem or at least helps the problem Terry. The real question, as you state, is the Internet ready to use this solution.

> I would certainly say that it makes intra-AS routing systems leaner, as a

And netflow caches smaller and EIDs in the underlay possibly private and more secure. All good things for USERS.

Agree.

> and move forward that way.

Agree 100%, but Prague will be used to brainstorm. Once we do that, we need to DECIDE on those priority items. Hope you will be there to contribute. You have a lot of experience with LISP deployemnt and can bring a lot of value to the discussion.

Thanks,
Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Jul 2015 10:17:40 -0700

> Hi Dino,

Hey Xiaohu.

> As an alternative VPN technology, what's the major benefit of LISP VPN compared to MPLS/BGP IP VPN?

You can put LISP-VPN anywhere. MPLS/BGP is typically run within a single service provider. With LISP-VPN, users can initiate and provision their own VPNs. That is just one difference.

> From the data plane perspective, given the fact that there is unprecedented enthusiasm for defining various data plane encapsulations (e.g., VXLAN, NVGRE, VXLAN-GPE, GUE-NVO, GENEVE...) , it seems…

There have been many pros and cons using BGP as a push control-plane and LISP as a control-plane. At the high-level, I’ll state one difference. The LISP control plane (the mapping database nodes), are in less places in the network than BGP nodes. So that means less coordination and management.

> Due to the new mobility requirements in 5G architecture (e.g., ultra-low latency), LISP-MN mobility may be a competitive candidate.

Why do you say that? Compared to other solutions its better. Or some technical aspect?

Dino

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 6 Jul 2015 01:47:21 +0000

Hi Dino,

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Saturday, July 04, 2015 1:18 AM
> To: Xuxiaohu
> Cc: Fabio Maino; LISP mailing list list
> You can put LISP-VPN anywhere. MPLS/BGP is typically run within a single
> service provider. With LISP-VPN, users can initiate and provision their own VPNs.
> That is just one difference.

If IP-based tunnels (e.g., MPLS-in-GRE or MPLS-in-UDP) are used between PE routers, is there still any difference on applicability between these two VPN technologies?

> > From the data plane perspective, given the fact that there is unprecedented
> enthusiasm for defining various data plane encapsulations (e.g., VXLAN, NVGRE,
> VXLAN-GPE, GUE-NVO, GENEVE...) , it seems no surprise to add two more (e.g.,
> LISP and LISP-GPE). From the control plane perspective, as BGP could be used as
> a pull-based control plane as well due to its prefix-ORF mechanism, what's the
> major advantage of LISP over BGP?
> 
> There have been many pros and cons using BGP as a push control-plane and
> LISP as a control-plane. At the high-level, I’ll state one difference. The LISP
> control plane (the mapping database nodes), are in less places in the network
> than BGP nodes. So that means less coordination and management.

In the data center network environment, route reflectors could be run over spine nodes or even servers. As such, these route reflectors could be looked as mapping database nodes. Hence, from the coordination and management perspectives, these two approaches seem almost the same, No?

> > Due to the new mobility requirements in 5G architecture (e.g., ultra-low
> latency), LISP-MN mobility may be a competitive candidate.
> 

Compared to other HA-based mobile IP solution, I think id/locator split solution looks better in the long run since it has the potential of eliminating the path stretch issue.

Best regards,
Xiaohu

> >> The last bullet is really important or you limit where you can deploy
> >> LISP. I have had a lot of implemetnation experience trying to get all
> >> the different LISP features to work across NATs. This includes and is
> >> not limited to RLOC-probing, lisp-crypto, multi-homing to multiple
> >> RTRs, xTRs behind multiple NATs and firewalls, and multicast.
> >>
> >>> opinion, the
> >> WG should consider to include in the charter: how to support a
> >> multi-protocol encapsulation that allows integration with IPsec,
> >> support for L2 overlays, and support for explicit tagging and
> >> supported encapsulations, and given the striking similarities with
> >> the LISP encap, I think the new drafts should be required to support
> >> both LISP and VXLAN-GPE encapsulations, as the LISP-GPE draft is trying to
> suggest.
> >>
> >> I think it is clear from the industry that the LISP control-plane can
> >> be used for multiple data-planes. So we should not limit or specify
> >> specifically (and not in one place) a single data-plane.
> >>
> >>> works
> >> across the areas described above. It's hard to make a priority, but
> >> probably the first 3 are the ones where the group can make
> >>
> >> “An overlay needs to move unicast and multicast packets in a secure
> >> and scalable way in public and private addressing environments”.
> >>
> >> That means:
> >>
> >> (2) We need to get VPNs to work when RLOCs and EIDs are private
> >> addresses and come from multiple address-families.
> >> These are not new work items or changes to the LISP architecture.
> >> They are all supported and implemented in various forms in both open and
> close products.
> >>
> >> with the greatest potential. Rather than making the charter
> >> exclusive, I would try to leave the door open. We can use milestones
> >> to prioritize the initial focus, but at least the WG has a way to later add work
> in those areas.
> >>
> >> categories, then a specific use-case as IoT or LISP-MN will just fit in one of
> those categories.
> >>
> >> Dino
> >>
> >>>
> >>> Thanks,
> >>> Fabio
> >>>
> >>>
> >>>
> >>>> Yours,
> >>>> Joel
> >>>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 6 Jul 2015 15:15:45 -0700

> If IP-based tunnels (e.g., MPLS-in-GRE or MPLS-in-UDP) are used between PE routers, is there still any difference on applicability between these two VPN technologies?

The mechanism and location of tunneling is not important. It is the type of service the solution can offer and what was intended in its initial design.

There is a lot of difference when you look at the type of services ISP based VPNs offer and what LISP VPNs offer with all the other solutions LISP can offer along with VPNs.

> In the data center network environment, route reflectors could be run over spine nodes or even servers. As such, these route reflectors could be looked as mapping database nodes. Hence, from the co…

Yes, but the information is pushed. At some point any protocol and architecture can be changed, used, or misused to look like another. But what is important is how it was designed from the beginning.

> Compared to other HA-based mobile IP solution, I think id/locator split solution looks better in the long run since it has the potential of eliminating the path stretch issue.

Right, agree.

Dino