Re: [lisp] 6830bis Review

[Reshad Rahman (rrahman)]

I also believe SMRs should be in the CP doc. I would support Dino’s  proposal 
below.

Regards,
Reshad.

On 2018-01-15, 2:10 PM, "lisp on behalf of Dino Farinacci" 
 wrote:

I’d be willing to make a deal.

SMRs go to 6833bis and RLOC-probes stay in 6830bis. Since RLOC-probes are 
connected (semantically) to echo-noncing which use bits in the LISP header.

Dino

> On Jan 15, 2018, at 10:32 AM, Alberto Rodriguez-Natal 
 wrote:
> 
> On Mon, Jan 15, 2018 at 6:55 PM, Dino Farinacci  
wrote:
>>> SMRs and RLOC-probes are control-plane features used by xTRs to be able 
to run the data-plane.
>> 
>> They are data-plane features that use control-plane messages. No other 
devices sends an RLOC-probe (or SMR) then an xTR.
> 
> IMHO I think that the SMR should go into the control-plane document. I
> believe that there are many cases (specially from an SDN point of
> view) where you may want to send SMRs from entities other than xTRs.
> 
> There's already a draft [1] that proposes that SMRs can also be sent
> by MSMRs. That draft is documenting what has been implemented and
> running on OpenDaylight for a while now.
> 
> Furthermore, lig-lispmob [2] supports sending SMRs on demand through a
> CLI without running an xTR. I've found that capability useful on many
> occasions.
> 
> Alberto
> 
> [1] https://tools.ietf.org/html/draft-rodrigueznatal-lisp-ms-smr-04
> [2] https://github.com/LISPmob/lig-lispmob

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Dino Farinacci]

I’d be willing to make a deal.

SMRs go to 6833bis and RLOC-probes stay in 6830bis. Since RLOC-probes are 
connected (semantically) to echo-noncing which use bits in the LISP header.

Dino

> On Jan 15, 2018, at 10:32 AM, Alberto Rodriguez-Natal 
>  wrote:
> 
> On Mon, Jan 15, 2018 at 6:55 PM, Dino Farinacci  wrote:
>>> SMRs and RLOC-probes are control-plane features used by xTRs to be able to 
>>> run the data-plane.
>> 
>> They are data-plane features that use control-plane messages. No other 
>> devices sends an RLOC-probe (or SMR) then an xTR.
> 
> IMHO I think that the SMR should go into the control-plane document. I
> believe that there are many cases (specially from an SDN point of
> view) where you may want to send SMRs from entities other than xTRs.
> 
> There's already a draft [1] that proposes that SMRs can also be sent
> by MSMRs. That draft is documenting what has been implemented and
> running on OpenDaylight for a while now.
> 
> Furthermore, lig-lispmob [2] supports sending SMRs on demand through a
> CLI without running an xTR. I've found that capability useful on many
> occasions.
> 
> Alberto
> 
> [1] https://tools.ietf.org/html/draft-rodrigueznatal-lisp-ms-smr-04
> [2] https://github.com/LISPmob/lig-lispmob

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Alberto Rodriguez-Natal]

On Mon, Jan 15, 2018 at 6:55 PM, Dino Farinacci  wrote:
>> SMRs and RLOC-probes are control-plane features used by xTRs to be able to 
>> run the data-plane.
>
> They are data-plane features that use control-plane messages. No other 
> devices sends an RLOC-probe (or SMR) then an xTR.

IMHO I think that the SMR should go into the control-plane document. I
believe that there are many cases (specially from an SDN point of
view) where you may want to send SMRs from entities other than xTRs.

There's already a draft [1] that proposes that SMRs can also be sent
by MSMRs. That draft is documenting what has been implemented and
running on OpenDaylight for a while now.

Furthermore, lig-lispmob [2] supports sending SMRs on demand through a
CLI without running an xTR. I've found that capability useful on many
occasions.

Alberto

[1] https://tools.ietf.org/html/draft-rodrigueznatal-lisp-ms-smr-04
[2] https://github.com/LISPmob/lig-lispmob

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Joel M. Halpern]

If there is silence, the chairs will make their best judgment on behalf 
of the working group.  That is our job.


The other choice is that we block the document until there are enough 
voices.  I would prefer not to do that.


Yours,
Joel

On 1/15/18 1:16 PM, Dino Farinacci wrote:

  (Yes, my hats are bouncing.)
I would really like to hear from other WG members about this.  It is the WGs 
document.  The chairs would prefer not to simply use their own judgment.  So to 
repeat Luigi's plea: speak up.



And if there is silence, then what?

Dino



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Dino Farinacci]

>   (Yes, my hats are bouncing.)
> I would really like to hear from other WG members about this.  It is the WGs 
> document.  The chairs would prefer not to simply use their own judgment.  So 
> to repeat Luigi's plea: speak up.
> 

And if there is silence, then what?

Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Joel M. Halpern]

 Let's try to separate things.

1) The fact that the messages are used only between xTRs does not tell 
us whether it is control or data.
2) The manipulation of map-cache may well be control (for example, if we 
were using a push-based control mechanism then map-cache control would 
be largely control.





Personally, it looks to me like SMR is a control mechanism.  It is 
information to control the operation of the xTR.  It is not data plane 
behavior.  It is driven from and drives control behavior.


One could argue that RLOC-probes are more borderline in tha tthey 
themselves behave more like data packets.  Still, my own thought process 
is to think of them as control operations.


The actual argument that can be made is that the capabilities these 
provide could be provided by another mechanism when another data plane 
is used.  But the capability needs to exist.  Putting these mechanisms 
in the control plane document makes it much easier to have the 
discussion about the fact that the control plane needs these functions 
to be robust.
After all, there is no goal that these are completely separate and 
independent entities.  Even if it may turn out that with sufficient care 
the control plane can be used for other things.



  (Yes, my hats are bouncing.)
I would really like to hear from other WG members about this.  It is the 
WGs document.  The chairs would prefer not to simply use their own 
judgment.  So to repeat Luigi's plea: speak up.



Yours,
Joel


On 1/15/18 12:55 PM, Dino Farinacci wrote:

SMRs and RLOC-probes are control-plane features used by xTRs to be able to run 
the data-plane.


They are data-plane features that use control-plane messages. No other devices 
sends an RLOC-probe (or SMR) then an xTR. And the elements of operation are 
based on the map-cache. Any manipulation of the map-cache SHOULD NOT go in 
6833bis.

Dino


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Dino Farinacci]

> SMRs and RLOC-probes are control-plane features used by xTRs to be able to 
> run the data-plane.

They are data-plane features that use control-plane messages. No other devices 
sends an RLOC-probe (or SMR) then an xTR. And the elements of operation are 
based on the map-cache. Any manipulation of the map-cache SHOULD NOT go in 
6833bis.

Dino


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Luigi Iannone]

> On 12 Jan 2018, at 18:38, Dino Farinacci  wrote:
> 
> Let me put it even simpler for you Luigi. Say someone wants to write a client 
> program that uses the LISP control-plane documented in 6833bis. A perfect 
> example of this is a lig client (RFC 6835). 
> 
> If SMRs and RLOC-Probing were to be documented in 6833bis, the lig client 
> implementor would be wondering if it needs to implement SMRs and RLOC-probes. 
> A lig client simply looks up an EID and prints out the RLOC-records.
> 
> Conclusion, SMRs and RLOC-probes are used by xTRs to be able to run the 
> data-plane.

SMRs and RLOC-probes are control-plane features used by xTRs to be able to run 
the data-plane.

As such they go in 6833bis.

L.



> xTRs are data-plane components. Therefore SMRs and RLOC-probes should stay in 
> 6830bis, the data-plane specification.
> 
> Dino
> 
>> On Jan 12, 2018, at 3:01 AM, Luigi Iannone  wrote:
>> 
>> 
>> 
>>> On 11 Jan 2018, at 18:50, Dino Farinacci  wrote:
>>> 
>>> Thanks Alberto for your comments. Here is how I break up items in the 
>>> control-plane and the data-plane. 
>>> 
>>> Control-Plane (6833bis document):
>>> 
>>> (1) The definition of control-plane messages. These are already documented 
>>> in 6833bis.
>>> (2) What components make up the control-plane that are not also in the 
>>> data-plane. That is Map-Servers, Map-Resovers, LISP-ALT nodes, LISP-DDT 
>>> nodes. These are already documented in 6833bis.
>>> 
>>> Data-Plane (6830bis document):
>>> 
>>> (1) What is required to move packets. Which includes the encapsulation 
>>> format and the database-mappings and map-cache xTRs use. These are already 
>>> documented in RFC6830bis.
>>> (2) The components that make up the data-plane. That is ITRs, ETRs, PxTRs, 
>>> and RTRs.
>>> (3) And the elements of operation that the components in (2) use. So 
>>> RLOC-probing and SMRs are explained in RFC6830bis because the components in 
>>> (2) use. They are using control-plane messages obviously but those messages 
>>> are defined in 6833bis.
>>> 
>>> Note that ETRs send SMRs, note ITRs and PITR send RLOC-probes. These 
>>> messages are not sent by any control-plane components. Another data-plane 
>>> can be defined to do its own OAM or map version updating and use the 
>>> messages defined in 6833bis to do that. But they could also might “let me 
>>> try to use the same map-cache mechanisms as LISP but use a different 
>>> encapsulation format”. In this case, an implementor or deployer would read 
>>> 6830bis.
>>> 
>>> Having said that, people don’t create walls between getting information so 
>>> if they want to do their own data-plane they can still read 6830bis.
>>> 
>>> Another point about SMRs, the entire section talks about what ITRs and ETRs 
>>> do. And these devices are data-plane components. Putting this section in 
>>> 6833bis would possibly surprise a reader implementing another data-plane. 
>>> For instance, a VXLAN data-plane reader would say “what is an ITR and ETR? 
>>> I have VTEPs”.
>> 
>> This reasoning does not hold.
>> 
>> [dhcp164-133] ~/Desktop # grep -c ITR draft-ietf-lisp-rfc6833bis-07.txt 
>> 65
>> [dhcp164-133] ~/Desktop # grep -c ETR draft-ietf-lisp-rfc6833bis-07.txt
>> 83
>> [dhcp164-133] ~/Desktop # grep -c xTR draft-ietf-lisp-rfc6833bis-07.txt
>> 20
>> [dhcp164-133] ~/Desktop # 
>> 
>> 
>> 
>> 
>> Whoever reads 6833bis has to know what an ITR and an ETR is and what it does.
>> 
>> L.
>> 
>> 
>>> Another point about SMRs, they can be data driven. This happens when an ITR 
>>> encapsulates to an ETR where the EID is no longer residing. That ETR, could 
>>> respond with a SMR to the ITR to inform it that it has out of date 
>>> mappings. This is all data-plane driven. Wouldn’t make logical sense to put 
>>> it in 6833bis.
>>> 
>>> Anyways, that is the way I look at it,
>>> Dino
>>> 
 On Jan 11, 2018, at 6:21 AM, Alberto Rodriguez-Natal 
  wrote:
 
 Adding my two cents to this discussion, in the hope that it helps with
 the convergence.
 
 My original hope with the reorganization of the RFCs was to be able to
 use the LISP control-plane with a non-LISP data-plane. Putting aside
 the discussion of what goes where, and with some pragmatism in mind, I
 think we're close to that with the current 6833bis. The major
 roadblock for me is the lack of SMR in that document, and I think this
 aligns with the view of others in the list.
 
 I believe that with the addition of SMR, 6833bis will have all the
 required pieces to put together a viable LISP deployment (using a
 non-LISP data-plane) without having to look into 6830bis. Sure, there
 would be some mechanisms (e.g. RLOC probing) that would not be
 available using only 6833bis, but I could live without those. In
 addition, we could work on adding some extra explanation to the
 introduction of 6833bis so a non-familiar reader could make use of
 LISP without looking into 6830bis.
 
 I think thes

Re: [lisp] 6830bis Review

[Dino Farinacci]

Let me put it even simpler for you Luigi. Say someone wants to write a client 
program that uses the LISP control-plane documented in 6833bis. A perfect 
example of this is a lig client (RFC 6835). 

If SMRs and RLOC-Probing were to be documented in 6833bis, the lig client 
implementor would be wondering if it needs to implement SMRs and RLOC-probes. A 
lig client simply looks up an EID and prints out the RLOC-records.

Conclusion, SMRs and RLOC-probes are used by xTRs to be able to run the 
data-plane. xTRs are data-plane components. Therefore SMRs and RLOC-probes 
should stay in 6830bis, the data-plane specification.

Dino

> On Jan 12, 2018, at 3:01 AM, Luigi Iannone  wrote:
> 
> 
> 
>> On 11 Jan 2018, at 18:50, Dino Farinacci  wrote:
>> 
>> Thanks Alberto for your comments. Here is how I break up items in the 
>> control-plane and the data-plane. 
>> 
>> Control-Plane (6833bis document):
>> 
>> (1) The definition of control-plane messages. These are already documented 
>> in 6833bis.
>> (2) What components make up the control-plane that are not also in the 
>> data-plane. That is Map-Servers, Map-Resovers, LISP-ALT nodes, LISP-DDT 
>> nodes. These are already documented in 6833bis.
>> 
>> Data-Plane (6830bis document):
>> 
>> (1) What is required to move packets. Which includes the encapsulation 
>> format and the database-mappings and map-cache xTRs use. These are already 
>> documented in RFC6830bis.
>> (2) The components that make up the data-plane. That is ITRs, ETRs, PxTRs, 
>> and RTRs.
>> (3) And the elements of operation that the components in (2) use. So 
>> RLOC-probing and SMRs are explained in RFC6830bis because the components in 
>> (2) use. They are using control-plane messages obviously but those messages 
>> are defined in 6833bis.
>> 
>> Note that ETRs send SMRs, note ITRs and PITR send RLOC-probes. These 
>> messages are not sent by any control-plane components. Another data-plane 
>> can be defined to do its own OAM or map version updating and use the 
>> messages defined in 6833bis to do that. But they could also might “let me 
>> try to use the same map-cache mechanisms as LISP but use a different 
>> encapsulation format”. In this case, an implementor or deployer would read 
>> 6830bis.
>> 
>> Having said that, people don’t create walls between getting information so 
>> if they want to do their own data-plane they can still read 6830bis.
>> 
>> Another point about SMRs, the entire section talks about what ITRs and ETRs 
>> do. And these devices are data-plane components. Putting this section in 
>> 6833bis would possibly surprise a reader implementing another data-plane. 
>> For instance, a VXLAN data-plane reader would say “what is an ITR and ETR? I 
>> have VTEPs”.
> 
> This reasoning does not hold.
> 
> [dhcp164-133] ~/Desktop # grep -c ITR draft-ietf-lisp-rfc6833bis-07.txt 
> 65
> [dhcp164-133] ~/Desktop # grep -c ETR draft-ietf-lisp-rfc6833bis-07.txt
> 83
> [dhcp164-133] ~/Desktop # grep -c xTR draft-ietf-lisp-rfc6833bis-07.txt
> 20
> [dhcp164-133] ~/Desktop # 
> 
> 
> 
> 
> Whoever reads 6833bis has to know what an ITR and an ETR is and what it does.
> 
> L.
> 
> 
>> Another point about SMRs, they can be data driven. This happens when an ITR 
>> encapsulates to an ETR where the EID is no longer residing. That ETR, could 
>> respond with a SMR to the ITR to inform it that it has out of date mappings. 
>> This is all data-plane driven. Wouldn’t make logical sense to put it in 
>> 6833bis.
>> 
>> Anyways, that is the way I look at it,
>> Dino
>> 
>>> On Jan 11, 2018, at 6:21 AM, Alberto Rodriguez-Natal 
>>>  wrote:
>>> 
>>> Adding my two cents to this discussion, in the hope that it helps with
>>> the convergence.
>>> 
>>> My original hope with the reorganization of the RFCs was to be able to
>>> use the LISP control-plane with a non-LISP data-plane. Putting aside
>>> the discussion of what goes where, and with some pragmatism in mind, I
>>> think we're close to that with the current 6833bis. The major
>>> roadblock for me is the lack of SMR in that document, and I think this
>>> aligns with the view of others in the list.
>>> 
>>> I believe that with the addition of SMR, 6833bis will have all the
>>> required pieces to put together a viable LISP deployment (using a
>>> non-LISP data-plane) without having to look into 6830bis. Sure, there
>>> would be some mechanisms (e.g. RLOC probing) that would not be
>>> available using only 6833bis, but I could live without those. In
>>> addition, we could work on adding some extra explanation to the
>>> introduction of 6833bis so a non-familiar reader could make use of
>>> LISP without looking into 6830bis.
>>> 
>>> I think these two things (i.e. move SMR and extend 6833bis intro)
>>> would minimize the changes required on the current documents and would
>>> allow us to reach some rough consensus to make progress with the docs.
>>> What do you guys think?
>>> 
>>> Alberto
>>> 
>>> On Wed, Jan 10, 2018 at 6:26 PM, Dino Farinacci  wrote:
>

Re: [lisp] 6830bis Review

[Luigi Iannone]

> On 11 Jan 2018, at 18:50, Dino Farinacci  wrote:
> 
> Thanks Alberto for your comments. Here is how I break up items in the 
> control-plane and the data-plane. 
> 
> Control-Plane (6833bis document):
> 
> (1) The definition of control-plane messages. These are already documented in 
> 6833bis.
> (2) What components make up the control-plane that are not also in the 
> data-plane. That is Map-Servers, Map-Resovers, LISP-ALT nodes, LISP-DDT 
> nodes. These are already documented in 6833bis.
> 
> Data-Plane (6830bis document):
> 
> (1) What is required to move packets. Which includes the encapsulation format 
> and the database-mappings and map-cache xTRs use. These are already 
> documented in RFC6830bis.
> (2) The components that make up the data-plane. That is ITRs, ETRs, PxTRs, 
> and RTRs.
> (3) And the elements of operation that the components in (2) use. So 
> RLOC-probing and SMRs are explained in RFC6830bis because the components in 
> (2) use. They are using control-plane messages obviously but those messages 
> are defined in 6833bis.
> 
> Note that ETRs send SMRs, note ITRs and PITR send RLOC-probes. These messages 
> are not sent by any control-plane components. Another data-plane can be 
> defined to do its own OAM or map version updating and use the messages 
> defined in 6833bis to do that. But they could also might “let me try to use 
> the same map-cache mechanisms as LISP but use a different encapsulation 
> format”. In this case, an implementor or deployer would read 6830bis.
> 
> Having said that, people don’t create walls between getting information so if 
> they want to do their own data-plane they can still read 6830bis.
> 
> Another point about SMRs, the entire section talks about what ITRs and ETRs 
> do. And these devices are data-plane components. Putting this section in 
> 6833bis would possibly surprise a reader implementing another data-plane. For 
> instance, a VXLAN data-plane reader would say “what is an ITR and ETR? I have 
> VTEPs”.

This reasoning does not hold.

[dhcp164-133] ~/Desktop # grep -c ITR draft-ietf-lisp-rfc6833bis-07.txt 
65
[dhcp164-133] ~/Desktop # grep -c ETR draft-ietf-lisp-rfc6833bis-07.txt
83
[dhcp164-133] ~/Desktop # grep -c xTR draft-ietf-lisp-rfc6833bis-07.txt
20
[dhcp164-133] ~/Desktop # 




Whoever reads 6833bis has to know what an ITR and an ETR is and what it does.

L.


> Another point about SMRs, they can be data driven. This happens when an ITR 
> encapsulates to an ETR where the EID is no longer residing. That ETR, could 
> respond with a SMR to the ITR to inform it that it has out of date mappings. 
> This is all data-plane driven. Wouldn’t make logical sense to put it in 
> 6833bis.
> 
> Anyways, that is the way I look at it,
> Dino
> 
>> On Jan 11, 2018, at 6:21 AM, Alberto Rodriguez-Natal 
>>  wrote:
>> 
>> Adding my two cents to this discussion, in the hope that it helps with
>> the convergence.
>> 
>> My original hope with the reorganization of the RFCs was to be able to
>> use the LISP control-plane with a non-LISP data-plane. Putting aside
>> the discussion of what goes where, and with some pragmatism in mind, I
>> think we're close to that with the current 6833bis. The major
>> roadblock for me is the lack of SMR in that document, and I think this
>> aligns with the view of others in the list.
>> 
>> I believe that with the addition of SMR, 6833bis will have all the
>> required pieces to put together a viable LISP deployment (using a
>> non-LISP data-plane) without having to look into 6830bis. Sure, there
>> would be some mechanisms (e.g. RLOC probing) that would not be
>> available using only 6833bis, but I could live without those. In
>> addition, we could work on adding some extra explanation to the
>> introduction of 6833bis so a non-familiar reader could make use of
>> LISP without looking into 6830bis.
>> 
>> I think these two things (i.e. move SMR and extend 6833bis intro)
>> would minimize the changes required on the current documents and would
>> allow us to reach some rough consensus to make progress with the docs.
>> What do you guys think?
>> 
>> Alberto
>> 
>> On Wed, Jan 10, 2018 at 6:26 PM, Dino Farinacci  wrote:
>>> From my perspective on the situation:
>>> 
>>> (1) I made changes exactly to text that was requested.
>>> (2) I sometimes modify what the text that was requested.
>>> (3) I disgree with some text so don’t include it.
>>> (4) I have made many sub-revisions of -08.
>>> (5) Comments are coming in throughout the review period and I don’t know 
>>> what revision you have read and what you have not read. I don’t know if 
>>> your comments are old or based on one of the revisions. Because I see 
>>> comments that I addressed but its not clear to me you know that (or at 
>>> least you have not told me).
>>> (6) The changes in (1) and (2) have not been confirmed or denied by 
>>> commenters. So I don’t know if what I changed has been accepted.
>>> (7) Adding text to something that has changed won’t go in prope

Re: [lisp] 6830bis Review

[Joel M. Halpern]

Working group:

I see folks making a case for SMR being in either 6830bis or 6833bis.
It is up to the WG.
What say you?

Yours,
Joel

On 1/11/18 12:50 PM, Dino Farinacci wrote:

Thanks Alberto for your comments. Here is how I break up items in the 
control-plane and the data-plane.

Control-Plane (6833bis document):

(1) The definition of control-plane messages. These are already documented in 
6833bis.
(2) What components make up the control-plane that are not also in the 
data-plane. That is Map-Servers, Map-Resovers, LISP-ALT nodes, LISP-DDT nodes. 
These are already documented in 6833bis.

Data-Plane (6830bis document):

(1) What is required to move packets. Which includes the encapsulation format 
and the database-mappings and map-cache xTRs use. These are already documented 
in RFC6830bis.
(2) The components that make up the data-plane. That is ITRs, ETRs, PxTRs, and 
RTRs.
(3) And the elements of operation that the components in (2) use. So 
RLOC-probing and SMRs are explained in RFC6830bis because the components in (2) 
use. They are using control-plane messages obviously but those messages are 
defined in 6833bis.

Note that ETRs send SMRs, note ITRs and PITR send RLOC-probes. These messages 
are not sent by any control-plane components. Another data-plane can be defined 
to do its own OAM or map version updating and use the messages defined in 
6833bis to do that. But they could also might “let me try to use the same 
map-cache mechanisms as LISP but use a different encapsulation format”. In this 
case, an implementor or deployer would read 6830bis.

Having said that, people don’t create walls between getting information so if 
they want to do their own data-plane they can still read 6830bis.

Another point about SMRs, the entire section talks about what ITRs and ETRs do. 
And these devices are data-plane components. Putting this section in 6833bis 
would possibly surprise a reader implementing another data-plane. For instance, 
a VXLAN data-plane reader would say “what is an ITR and ETR? I have VTEPs”. 
Another point about SMRs, they can be data driven. This happens when an ITR 
encapsulates to an ETR where the EID is no longer residing. That ETR, could 
respond with a SMR to the ITR to inform it that it has out of date mappings. 
This is all data-plane driven. Wouldn’t make logical sense to put it in 6833bis.

Anyways, that is the way I look at it,
Dino


On Jan 11, 2018, at 6:21 AM, Alberto Rodriguez-Natal  
wrote:

Adding my two cents to this discussion, in the hope that it helps with
the convergence.

My original hope with the reorganization of the RFCs was to be able to
use the LISP control-plane with a non-LISP data-plane. Putting aside
the discussion of what goes where, and with some pragmatism in mind, I
think we're close to that with the current 6833bis. The major
roadblock for me is the lack of SMR in that document, and I think this
aligns with the view of others in the list.

I believe that with the addition of SMR, 6833bis will have all the
required pieces to put together a viable LISP deployment (using a
non-LISP data-plane) without having to look into 6830bis. Sure, there
would be some mechanisms (e.g. RLOC probing) that would not be
available using only 6833bis, but I could live without those. In
addition, we could work on adding some extra explanation to the
introduction of 6833bis so a non-familiar reader could make use of
LISP without looking into 6830bis.

I think these two things (i.e. move SMR and extend 6833bis intro)
would minimize the changes required on the current documents and would
allow us to reach some rough consensus to make progress with the docs.
What do you guys think?

Alberto

On Wed, Jan 10, 2018 at 6:26 PM, Dino Farinacci  wrote:

 From my perspective on the situation:

(1) I made changes exactly to text that was requested.
(2) I sometimes modify what the text that was requested.
(3) I disgree with some text so don’t include it.
(4) I have made many sub-revisions of -08.
(5) Comments are coming in throughout the review period and I don’t know what 
revision you have read and what you have not read. I don’t know if your 
comments are old or based on one of the revisions. Because I see comments that 
I addressed but its not clear to me you know that (or at least you have not 
told me).
(6) The changes in (1) and (2) have not been confirmed or denied by commenters. 
So I don’t know if what I changed has been accepted.
(7) Adding text to something that has changed won’t go in properly. So 
referencing some offered text in a previous email can’t be just inserted.

So -08 has been submitted. I don’t know what are the outstanding issues at this 
point. So I need commenters to be specific. This is what I suggest:

(1) List the open issues by commenting on the latest submitted -08.
(2) Include text from the -08 draft and your comments follow with suggested 
text.

Let’s use that as a base to comment and discuss further. I can’t read your 
minds so I need more of you

Re: [lisp] 6830bis Review

[Dino Farinacci]

Thanks Alberto for your comments. Here is how I break up items in the 
control-plane and the data-plane. 

Control-Plane (6833bis document):

(1) The definition of control-plane messages. These are already documented in 
6833bis.
(2) What components make up the control-plane that are not also in the 
data-plane. That is Map-Servers, Map-Resovers, LISP-ALT nodes, LISP-DDT nodes. 
These are already documented in 6833bis.

Data-Plane (6830bis document):

(1) What is required to move packets. Which includes the encapsulation format 
and the database-mappings and map-cache xTRs use. These are already documented 
in RFC6830bis.
(2) The components that make up the data-plane. That is ITRs, ETRs, PxTRs, and 
RTRs.
(3) And the elements of operation that the components in (2) use. So 
RLOC-probing and SMRs are explained in RFC6830bis because the components in (2) 
use. They are using control-plane messages obviously but those messages are 
defined in 6833bis.

Note that ETRs send SMRs, note ITRs and PITR send RLOC-probes. These messages 
are not sent by any control-plane components. Another data-plane can be defined 
to do its own OAM or map version updating and use the messages defined in 
6833bis to do that. But they could also might “let me try to use the same 
map-cache mechanisms as LISP but use a different encapsulation format”. In this 
case, an implementor or deployer would read 6830bis.

Having said that, people don’t create walls between getting information so if 
they want to do their own data-plane they can still read 6830bis.

Another point about SMRs, the entire section talks about what ITRs and ETRs do. 
And these devices are data-plane components. Putting this section in 6833bis 
would possibly surprise a reader implementing another data-plane. For instance, 
a VXLAN data-plane reader would say “what is an ITR and ETR? I have VTEPs”. 
Another point about SMRs, they can be data driven. This happens when an ITR 
encapsulates to an ETR where the EID is no longer residing. That ETR, could 
respond with a SMR to the ITR to inform it that it has out of date mappings. 
This is all data-plane driven. Wouldn’t make logical sense to put it in 6833bis.

Anyways, that is the way I look at it,
Dino

> On Jan 11, 2018, at 6:21 AM, Alberto Rodriguez-Natal 
>  wrote:
> 
> Adding my two cents to this discussion, in the hope that it helps with
> the convergence.
> 
> My original hope with the reorganization of the RFCs was to be able to
> use the LISP control-plane with a non-LISP data-plane. Putting aside
> the discussion of what goes where, and with some pragmatism in mind, I
> think we're close to that with the current 6833bis. The major
> roadblock for me is the lack of SMR in that document, and I think this
> aligns with the view of others in the list.
> 
> I believe that with the addition of SMR, 6833bis will have all the
> required pieces to put together a viable LISP deployment (using a
> non-LISP data-plane) without having to look into 6830bis. Sure, there
> would be some mechanisms (e.g. RLOC probing) that would not be
> available using only 6833bis, but I could live without those. In
> addition, we could work on adding some extra explanation to the
> introduction of 6833bis so a non-familiar reader could make use of
> LISP without looking into 6830bis.
> 
> I think these two things (i.e. move SMR and extend 6833bis intro)
> would minimize the changes required on the current documents and would
> allow us to reach some rough consensus to make progress with the docs.
> What do you guys think?
> 
> Alberto
> 
> On Wed, Jan 10, 2018 at 6:26 PM, Dino Farinacci  wrote:
>> From my perspective on the situation:
>> 
>> (1) I made changes exactly to text that was requested.
>> (2) I sometimes modify what the text that was requested.
>> (3) I disgree with some text so don’t include it.
>> (4) I have made many sub-revisions of -08.
>> (5) Comments are coming in throughout the review period and I don’t know 
>> what revision you have read and what you have not read. I don’t know if your 
>> comments are old or based on one of the revisions. Because I see comments 
>> that I addressed but its not clear to me you know that (or at least you have 
>> not told me).
>> (6) The changes in (1) and (2) have not been confirmed or denied by 
>> commenters. So I don’t know if what I changed has been accepted.
>> (7) Adding text to something that has changed won’t go in properly. So 
>> referencing some offered text in a previous email can’t be just inserted.
>> 
>> So -08 has been submitted. I don’t know what are the outstanding issues at 
>> this point. So I need commenters to be specific. This is what I suggest:
>> 
>> (1) List the open issues by commenting on the latest submitted -08.
>> (2) Include text from the -08 draft and your comments follow with suggested 
>> text.
>> 
>> Let’s use that as a base to comment and discuss further. I can’t read your 
>> minds so I need more of your help. So please put more effort into it.
>> 

Re: [lisp] 6830bis Review

[Alberto Rodriguez-Natal]

Adding my two cents to this discussion, in the hope that it helps with
the convergence.

My original hope with the reorganization of the RFCs was to be able to
use the LISP control-plane with a non-LISP data-plane. Putting aside
the discussion of what goes where, and with some pragmatism in mind, I
think we're close to that with the current 6833bis. The major
roadblock for me is the lack of SMR in that document, and I think this
aligns with the view of others in the list.

I believe that with the addition of SMR, 6833bis will have all the
required pieces to put together a viable LISP deployment (using a
non-LISP data-plane) without having to look into 6830bis. Sure, there
would be some mechanisms (e.g. RLOC probing) that would not be
available using only 6833bis, but I could live without those. In
addition, we could work on adding some extra explanation to the
introduction of 6833bis so a non-familiar reader could make use of
LISP without looking into 6830bis.

I think these two things (i.e. move SMR and extend 6833bis intro)
would minimize the changes required on the current documents and would
allow us to reach some rough consensus to make progress with the docs.
What do you guys think?

Alberto

On Wed, Jan 10, 2018 at 6:26 PM, Dino Farinacci  wrote:
> From my perspective on the situation:
>
> (1) I made changes exactly to text that was requested.
> (2) I sometimes modify what the text that was requested.
> (3) I disgree with some text so don’t include it.
> (4) I have made many sub-revisions of -08.
> (5) Comments are coming in throughout the review period and I don’t know what 
> revision you have read and what you have not read. I don’t know if your 
> comments are old or based on one of the revisions. Because I see comments 
> that I addressed but its not clear to me you know that (or at least you have 
> not told me).
> (6) The changes in (1) and (2) have not been confirmed or denied by 
> commenters. So I don’t know if what I changed has been accepted.
> (7) Adding text to something that has changed won’t go in properly. So 
> referencing some offered text in a previous email can’t be just inserted.
>
> So -08 has been submitted. I don’t know what are the outstanding issues at 
> this point. So I need commenters to be specific. This is what I suggest:
>
> (1) List the open issues by commenting on the latest submitted -08.
> (2) Include text from the -08 draft and your comments follow with suggested 
> text.
>
> Let’s use that as a base to comment and discuss further. I can’t read your 
> minds so I need more of your help. So please put more effort into it.
>
> Thanks in advance for your support,
> Dino
>
>
>> On Jan 10, 2018, at 2:03 AM, Luigi Iannone  wrote:
>>
>> Dino,
>>
>>> On 9 Jan 2018, at 18:54, Dino Farinacci  wrote:
>>>
>>> Guys, please look at the latest changes instead of hashing the same 
>>> arguments.
>>>
>>> This is what I am going to do. I am going to submit the myriad of changes 
>>> already agreed to and then we can open up comments again for -08. I have 
>>> been holding these diffs for a few weeks now and have received little 
>>> commentary on the latest changes. So if your points have not been 
>>> addressed, state them again AFTER reading the changes to -08.
>>>
>>
>> I find this request unfair.
>> I spent quite a bit of time reviewing and discussing this document, now you 
>> just try to wash all out by requesting comments on -08.
>>
>> Please let's continue discussing on the open issues so to find a solution.
>>
>> Thanks
>>
>> Luigi
>>
>>
>>
>>> The diff of the changes are included yet again.
>>>
>>> Dino
>>>
>>> 
>>>
 On Jan 9, 2018, at 7:04 AM, Luigi Iannone  wrote:


 HI Albert,

 thanks for your reply.

 My comments inline. (trimming what is OK for me)

 Luigi

> On 27 Dec 2017, at 02:48, Albert Cabellos  
> wrote:
>

 [snip]
>>
>>
>> Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
>>IPv6) value used in the source and destination address fields of
>>the first (most inner) LISP header of a packet.  The host obtains
>>a destination EID the same way it obtains a destination address
>>today, for example, through a Domain Name System (DNS) [RFC1034]
>>lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
>>The source EID is obtained via existing mechanisms used to set a
>>host's "local" IP address.  An EID used on the public Internet
>>must have the same properties as any other IP address used in that
>>manner; this means, among other things, that it must be globally
>>unique.  An EID is allocated to a host from an EID-Prefix block
>>associated with the site where the host is located.  An EID can be
>>used by a host to refer to other hosts.  Note that EID blocks MAY
>>be assigned in a hierarchical manner, independent of the network
>>topology, to facilitate sc

Re: [lisp] 6830bis Review

[Dino Farinacci]

From my perspective on the situation:

(1) I made changes exactly to text that was requested.
(2) I sometimes modify what the text that was requested.
(3) I disgree with some text so don’t include it.
(4) I have made many sub-revisions of -08.
(5) Comments are coming in throughout the review period and I don’t know what 
revision you have read and what you have not read. I don’t know if your 
comments are old or based on one of the revisions. Because I see comments that 
I addressed but its not clear to me you know that (or at least you have not 
told me).
(6) The changes in (1) and (2) have not been confirmed or denied by commenters. 
So I don’t know if what I changed has been accepted.
(7) Adding text to something that has changed won’t go in properly. So 
referencing some offered text in a previous email can’t be just inserted.

So -08 has been submitted. I don’t know what are the outstanding issues at this 
point. So I need commenters to be specific. This is what I suggest:

(1) List the open issues by commenting on the latest submitted -08.
(2) Include text from the -08 draft and your comments follow with suggested 
text.

Let’s use that as a base to comment and discuss further. I can’t read your 
minds so I need more of your help. So please put more effort into it.

Thanks in advance for your support,
Dino


> On Jan 10, 2018, at 2:03 AM, Luigi Iannone  wrote:
> 
> Dino,
> 
>> On 9 Jan 2018, at 18:54, Dino Farinacci  wrote:
>> 
>> Guys, please look at the latest changes instead of hashing the same 
>> arguments. 
>> 
>> This is what I am going to do. I am going to submit the myriad of changes 
>> already agreed to and then we can open up comments again for -08. I have 
>> been holding these diffs for a few weeks now and have received little 
>> commentary on the latest changes. So if your points have not been addressed, 
>> state them again AFTER reading the changes to -08.
>> 
> 
> I find this request unfair. 
> I spent quite a bit of time reviewing and discussing this document, now you 
> just try to wash all out by requesting comments on -08.
> 
> Please let's continue discussing on the open issues so to find a solution.
> 
> Thanks
> 
> Luigi
> 
> 
> 
>> The diff of the changes are included yet again.
>> 
>> Dino
>> 
>> 
>> 
>>> On Jan 9, 2018, at 7:04 AM, Luigi Iannone  wrote:
>>> 
>>> 
>>> HI Albert,
>>> 
>>> thanks for your reply. 
>>> 
>>> My comments inline. (trimming what is OK for me)
>>> 
>>> Luigi
>>> 
 On 27 Dec 2017, at 02:48, Albert Cabellos  
 wrote:
 
>>> 
>>> [snip]
> 
> 
> Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
>IPv6) value used in the source and destination address fields of
>the first (most inner) LISP header of a packet.  The host obtains
>a destination EID the same way it obtains a destination address
>today, for example, through a Domain Name System (DNS) [RFC1034]
>lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
>The source EID is obtained via existing mechanisms used to set a
>host's "local" IP address.  An EID used on the public Internet
>must have the same properties as any other IP address used in that
>manner; this means, among other things, that it must be globally
>unique.  An EID is allocated to a host from an EID-Prefix block
>associated with the site where the host is located.  An EID can be
>used by a host to refer to other hosts.  Note that EID blocks MAY
>be assigned in a hierarchical manner, independent of the network
>topology, to facilitate scaling of the mapping database.  In
>addition, an EID block assigned to a site may have site-local
>structure (subnetting) for routing within the site; this structure
>is not visible to the global routing system.  In theory, the bit
>string that represents an EID for one device can represent an RLOC
>for a different device.  As the architecture is realized, if a
>given bit string is both an RLOC and an EID, it must refer to the
>same entity in both cases.
> 
> 
> Is the above sentence really necessary?
> 
 
 Agreed, why not simplify the definitions. They are written from the 
 ‘Internet scalability mindset’, why not say that an EID is an address of 
 the overlay and an RLOC an address of the overlay. This change may require 
 further changes on the document so I am not 100% sure if this is a good 
 idea.
>>> 
>>> For clarification I was just referring to the sentence:
>>> 
>>> " As the architecture is realized, if a given bit string is both an RLOC 
>>> and an EID, it must refer to the same entity in both cases.” 
>>> 
>>> I am wondering if such constrain is really necessary. If namespaces are 
>>> well scoped there is no need for this. 
>>> 
>>> [snip]
>>> 
>>> About the following:
>>> 
 
> 
> o  EIDs are typically IP addresses assigned t

Re: [lisp] 6830bis Review

[Damien Saucez]

Hello Dino,

Thanks for the efforts.

The propositions in -08 are fine but are addressing only minor
details. As long as the structure of the document is not
fundamentally re-worked the document will remain poor and
barely readable for who doesn’t know LISP yet.

I already clearly gave my comments about all this, I don’t need
to repeat myself.

Regards,

Damien Saucez

> On 9 Jan 2018, at 18:54, Dino Farinacci  wrote:
> 
> Guys, please look at the latest changes instead of hashing the same 
> arguments. 
> 
> This is what I am going to do. I am going to submit the myriad of changes 
> already agreed to and then we can open up comments again for -08. I have been 
> holding these diffs for a few weeks now and have received little commentary 
> on the latest changes. So if your points have not been addressed, state them 
> again AFTER reading the changes to -08.
> 
> The diff of the changes are included yet again.
> 
> Dino
> 
> 
> 
>> On Jan 9, 2018, at 7:04 AM, Luigi Iannone  wrote:
>> 
>> 
>> HI Albert,
>> 
>> thanks for your reply. 
>> 
>> My comments inline. (trimming what is OK for me)
>> 
>> Luigi
>> 
>>> On 27 Dec 2017, at 02:48, Albert Cabellos  wrote:
>>> 
>> 
>> [snip]
 
 
  Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
 IPv6) value used in the source and destination address fields of
 the first (most inner) LISP header of a packet.  The host obtains
 a destination EID the same way it obtains a destination address
 today, for example, through a Domain Name System (DNS) [RFC1034]
 lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
 The source EID is obtained via existing mechanisms used to set a
 host's "local" IP address.  An EID used on the public Internet
 must have the same properties as any other IP address used in that
 manner; this means, among other things, that it must be globally
 unique.  An EID is allocated to a host from an EID-Prefix block
 associated with the site where the host is located.  An EID can be
 used by a host to refer to other hosts.  Note that EID blocks MAY
 be assigned in a hierarchical manner, independent of the network
 topology, to facilitate scaling of the mapping database.  In
 addition, an EID block assigned to a site may have site-local
 structure (subnetting) for routing within the site; this structure
 is not visible to the global routing system.  In theory, the bit
 string that represents an EID for one device can represent an RLOC
 for a different device.  As the architecture is realized, if a
 given bit string is both an RLOC and an EID, it must refer to the
 same entity in both cases.
 
 
 Is the above sentence really necessary?
 
>>> 
>>> Agreed, why not simplify the definitions. They are written from the 
>>> ‘Internet scalability mindset’, why not say that an EID is an address of 
>>> the overlay and an RLOC an address of the overlay. This change may require 
>>> further changes on the document so I am not 100% sure if this is a good 
>>> idea.
>> 
>> For clarification I was just referring to the sentence:
>> 
>> " As the architecture is realized, if a given bit string is both an RLOC and 
>> an EID, it must refer to the same entity in both cases.” 
>> 
>> I am wondering if such constrain is really necessary. If namespaces are well 
>> scoped there is no need for this. 
>> 
>> [snip]
>> 
>> About the following:
>> 
>>> 
 
  o  EIDs are typically IP addresses assigned to hosts.
 
  o  Other types of EID are supported by LISP, see [RFC8060] for
 further information.
 
 I would put the last two bullets in the definition of EID. It simplifies 
 the story here.
 
 
>>> 
>>> I suggest to leave them here, I don´t think that readers start from the 
>>> ‘Definition of terms’, these are relevant concepts to understand LISP.
>> 
>> Good point about de definition of terms. What really bothers me is the 
>> bullet organisation. What can be done is to merge these two bullets with the 
>> previous one. 
>> 
>>> 
 
 The description of the encap/decap operation lacks of clarity concerning 
 how to deal with
 ECN bits and DSCP .
 
 1. I think that the text should make explicitly the difference between 
 DSCP and ECN fields.
 
 2. How to deal with ECN should be part of the description of the  
 encap/decap not a paragraph apart.
   This basically means that half of the last paragraph should be a bullet 
 of the ITR/PITR encapsulation
   and the other half  in the ETR/PETR operation.
>>> 
>>> 
>>> Agreed, what about this (please comment):
>>> 
>>>   When doing ITR/PITR encapsulation:
>>> 
>>>o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the 
>>> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
>>>o  

Re: [lisp] 6830bis Review

[Luigi Iannone]

Dino,

> On 9 Jan 2018, at 18:54, Dino Farinacci  wrote:
> 
> Guys, please look at the latest changes instead of hashing the same 
> arguments. 
> 
> This is what I am going to do. I am going to submit the myriad of changes 
> already agreed to and then we can open up comments again for -08. I have been 
> holding these diffs for a few weeks now and have received little commentary 
> on the latest changes. So if your points have not been addressed, state them 
> again AFTER reading the changes to -08.
> 

I find this request unfair. 
I spent quite a bit of time reviewing and discussing this document, now you 
just try to wash all out by requesting comments on -08.

Please let's continue discussing on the open issues so to find a solution.

Thanks

Luigi



> The diff of the changes are included yet again.
> 
> Dino
> 
> 
> 
>> On Jan 9, 2018, at 7:04 AM, Luigi Iannone  wrote:
>> 
>> 
>> HI Albert,
>> 
>> thanks for your reply. 
>> 
>> My comments inline. (trimming what is OK for me)
>> 
>> Luigi
>> 
>>> On 27 Dec 2017, at 02:48, Albert Cabellos  wrote:
>>> 
>> 
>> [snip]
 
 
  Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
 IPv6) value used in the source and destination address fields of
 the first (most inner) LISP header of a packet.  The host obtains
 a destination EID the same way it obtains a destination address
 today, for example, through a Domain Name System (DNS) [RFC1034]
 lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
 The source EID is obtained via existing mechanisms used to set a
 host's "local" IP address.  An EID used on the public Internet
 must have the same properties as any other IP address used in that
 manner; this means, among other things, that it must be globally
 unique.  An EID is allocated to a host from an EID-Prefix block
 associated with the site where the host is located.  An EID can be
 used by a host to refer to other hosts.  Note that EID blocks MAY
 be assigned in a hierarchical manner, independent of the network
 topology, to facilitate scaling of the mapping database.  In
 addition, an EID block assigned to a site may have site-local
 structure (subnetting) for routing within the site; this structure
 is not visible to the global routing system.  In theory, the bit
 string that represents an EID for one device can represent an RLOC
 for a different device.  As the architecture is realized, if a
 given bit string is both an RLOC and an EID, it must refer to the
 same entity in both cases.
 
 
 Is the above sentence really necessary?
 
>>> 
>>> Agreed, why not simplify the definitions. They are written from the 
>>> ‘Internet scalability mindset’, why not say that an EID is an address of 
>>> the overlay and an RLOC an address of the overlay. This change may require 
>>> further changes on the document so I am not 100% sure if this is a good 
>>> idea.
>> 
>> For clarification I was just referring to the sentence:
>> 
>> " As the architecture is realized, if a given bit string is both an RLOC and 
>> an EID, it must refer to the same entity in both cases.” 
>> 
>> I am wondering if such constrain is really necessary. If namespaces are well 
>> scoped there is no need for this. 
>> 
>> [snip]
>> 
>> About the following:
>> 
>>> 
 
  o  EIDs are typically IP addresses assigned to hosts.
 
  o  Other types of EID are supported by LISP, see [RFC8060] for
 further information.
 
 I would put the last two bullets in the definition of EID. It simplifies 
 the story here.
 
 
>>> 
>>> I suggest to leave them here, I don´t think that readers start from the 
>>> ‘Definition of terms’, these are relevant concepts to understand LISP.
>> 
>> Good point about de definition of terms. What really bothers me is the 
>> bullet organisation. What can be done is to merge these two bullets with the 
>> previous one. 
>> 
>>> 
 
 The description of the encap/decap operation lacks of clarity concerning 
 how to deal with
 ECN bits and DSCP .
 
 1. I think that the text should make explicitly the difference between 
 DSCP and ECN fields.
 
 2. How to deal with ECN should be part of the description of the  
 encap/decap not a paragraph apart.
   This basically means that half of the last paragraph should be a bullet 
 of the ITR/PITR encapsulation
   and the other half  in the ETR/PETR operation.
>>> 
>>> 
>>> Agreed, what about this (please comment):
>>> 
>>>   When doing ITR/PITR encapsulation:
>>> 
>>>o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the 
>>> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
>>>o  The outer-header 'Differentiated Services Code Point' (DSCP) field 
>>> (or the 'Traffic Class' field, in th

Re: [lisp] 6830bis Review (PLEASE COMMENTS)

[Luigi Iannone]

> On 9 Jan 2018, at 19:00, Dino Farinacci  wrote:
> 
> Brief reply.
> 
> 
> The OAM information is necessary for the data-plane. And if LISP-GPE, 
> VXLAN, or any other data plane wants to use their own OAM or use the LISP 
> control-plane differently, it needs to be documented in their 
> data-planes. Hence, why this information is there.
 
 Doesn’t make sense to me. That is not a reason. 
>>> 
>>> It is a reason, maybe one you don’t like, but it is a reason.
>>> 
>> 
>> The point is that in the current document there is a lot of OAM text that 
>> does not belong to the data-plane. 
> 
> The OAM mechanisms are only used for data-plane purposes and to manage the 
> elements in the map-cache.

You just mixed up data-plane and control plane, hence, would be better move the 
OAM text


> It’s the only place it should go.
> 
>> 
>> 
 That information can be available in another document and still be used by 
 LISP-GPE, VxLAN, or any other data plane.
>>> 
>>> But we decided on only 2 documents. And if we put data-plane usage in a 
>>> control-plane document, then we are making 6833bis like 6830.
>>> 
>> 
>> We are better organising the specifications so that they are clearer and 
>> easier to read.
> 
> 
>> 
>> 
>> [snip]
>>> 
>> You break the operational flow by opening a different point describing 
>> what is what. It makes the overall procedure unclear.
> 
> It was put there because someone commented on it. You have to tell me why 
> you think it breaks flow. We discuss how end-systems send to EIDs. We say 
> what EIDs are and how they are assigned to hosts. And then we move to 
> RLOCs. It is pretty plan, simple, and straight-forward.
> 
 
 Those two point would have more emphasis somewhere else. 
 Where they are now they break the flow and do not provide details.
>>> 
>>> Unless you provide clear text where they should go, I’m not going to change 
>>> it.
>>> 
>> 
>> Suggested to merge with previous bullet in the reply to Albert.
> 
> Sorry the references to references do not help. I want a comment to the -08 
> text.

Please read reply to Albert.


> 
>>> I made some minor comments but do not want to undo what David Black spent 
>>> effort on and got approval for. And I certainly don’t want to repeat text 
>>> as you suggested above.
>>> 
>> 
>> The text provided by Albert is very good, I will ask David to review the 
>> text again to make sure nothing has been lost.
> 
> Sorry the references to references do not help. I want a comment to the -08 
> text.

Please read reply to Albert.

> 
>> As I suggested in first mail: 
>> 
>> We need to keep: 1, 6, Echo-Nonce, 
>> 
>> We need to move: 2, 3, 4, 5,  RLOC-Probing
> 
> Sorry, I can’t follow these references.

Please read reply to Albert and my original review.

Thanks

L.



> 
> Dino
> 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review (PLEASE COMMENTS)

[Dino Farinacci]

Brief reply.

 
 The OAM information is necessary for the data-plane. And if LISP-GPE, 
 VXLAN, or any other data plane wants to use their own OAM or use the LISP 
 control-plane differently, it needs to be documented in their data-planes. 
 Hence, why this information is there.
>>> 
>>> Doesn’t make sense to me. That is not a reason. 
>> 
>> It is a reason, maybe one you don’t like, but it is a reason.
>> 
> 
> The point is that in the current document there is a lot of OAM text that 
> does not belong to the data-plane. 

The OAM mechanisms are only used for data-plane purposes and to manage the 
elements in the map-cache. It’s the only place it should go.

> 
> 
>>> That information can be available in another document and still be used by 
>>> LISP-GPE, VxLAN, or any other data plane.
>> 
>> But we decided on only 2 documents. And if we put data-plane usage in a 
>> control-plane document, then we are making 6833bis like 6830.
>> 
> 
> We are better organising the specifications so that they are clearer and 
> easier to read.


> 
> 
> [snip]
>> 
> You break the operational flow by opening a different point describing 
> what is what. It makes the overall procedure unclear.
 
 It was put there because someone commented on it. You have to tell me why 
 you think it breaks flow. We discuss how end-systems send to EIDs. We say 
 what EIDs are and how they are assigned to hosts. And then we move to 
 RLOCs. It is pretty plan, simple, and straight-forward.
 
>>> 
>>> Those two point would have more emphasis somewhere else. 
>>> Where they are now they break the flow and do not provide details.
>> 
>> Unless you provide clear text where they should go, I’m not going to change 
>> it.
>> 
> 
> Suggested to merge with previous bullet in the reply to Albert.

Sorry the references to references do not help. I want a comment to the -08 
text.

>> I made some minor comments but do not want to undo what David Black spent 
>> effort on and got approval for. And I certainly don’t want to repeat text as 
>> you suggested above.
>> 
> 
> The text provided by Albert is very good, I will ask David to review the text 
> again to make sure nothing has been lost.

Sorry the references to references do not help. I want a comment to the -08 
text.

> As I suggested in first mail: 
> 
> We need to keep: 1, 6, Echo-Nonce, 
> 
> We need to move: 2, 3, 4, 5,  RLOC-Probing

Sorry, I can’t follow these references.

Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Luigi Iannone]

Hi,

On 27 Dec 2017, at 05:13, Dino Farinacci  wrote:
> 


[snip]
>> Agreed, what about this (please comment):
>> 
>>  When doing ITR/PITR encapsulation:
>> 
>>   o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the 
>> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
>>   o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or 
>> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the 
>> inner-header DSCP field ('Traffic Class' field, in the case of IPv6) 
>> considering the exception listed below.
>>  o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the 
>> IPv6 'Traffic Class' field) requires special treatment in order to avoid 
>> discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy 
>> the 2-bit 'ECN' field from the inner header to the outer header. 
>> Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer 
>> header to the new outer header.
>> 
>> When doing ETR/PETR decapsulation:
>> 
>>  o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case 
>> of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when 
>> the Time to Live value of the outer header is less than the Time to Live 
>> value of the inner header.  Failing to perform this check can cause the Time 
>> to Live of the inner header to increment across encapsulation/decapsulation 
>> cycles.  This check is also performed when doing initial encapsulation, when 
>> a packet comes to an ITR or PITR destined for a LISP site.
>>  o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or 
>> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the 
>> outer-header DSCP field ('Traffic Class' field, in the case of IPv6) 
>> considering the exception listed below.
>>  o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the 
>> IPv6 'Traffic Class' field) requires special treatment in order to avoid 
>> discarding indications of congestion [RFC3168]. If the 'ECN' field contains 
>> a congestion indication codepoint (the value is '11', the Congestion 
>> Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 
>> 'ECN' field from the stripped outer header to the surviving inner header 
>> that is used to forward the packet beyond the ETR.  These requirements 
>> preserve CE indications when a packet that uses ECN traverses a LISP tunnel 
>> and becomes marked with a CE indication due to congestion between the tunnel 
>> endpoints.
>> 
>> Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate 
>> after decapsulating, the net effect of this is that the new outer header 
>> will carry the same Time to Live as the old outer header minus 1.
>> 
>> Copying the Time to Live (TTL) serves two purposes: first, it preserves the 
>> distance the host intended the packet to travel; second, and more 
>> importantly, it provides for suppression of looping packets in the event 
>> there is a loop of concatenated tunnels due to misconfiguration.  See 
>> Section 18.3 for TTL exception handling for traceroute packets.
> 
> I had planned to take Luigi’s suggestion. I did not want to rewrite this 
> section. It was carefully written by David Black with consolation from the 
> ECN experts. I do not want to lose this technical text.

The text proposed by Albert is very close to the original and has exactly the 
same content, just expressed in an clearer way. No loss here.
I will ask David to review the text again.

The current text in section 5.3 is still not correct because it talks about 
“type of service” and “ECN”. 

Luigi



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review (PLEASE COMMENTS)

[Luigi Iannone]

Hi Dino,

my detailed comments are inline as usual, but I was wondering if is there a 
strong valid reason not to move text around?

The objective of this documentation is to be accessible easily by anyone that 
is willing to work or implement LISP, not only to specialist. The decomposition 
of functionality is thus essential so people don’t have to make important 
effort to understand what is strictly LISP encapsulation data-plane (specific 
to this encapsulation method), what is operation of the system, and what is 
control-plane (general to any encapsulation below).
> 



> On 27 Dec 2017, at 05:54, Dino Farinacci  > wrote:
> 
> New update included. I have made a lot of your requested changes but still 
> disagree with many of your points. More justification below.
> 
>>> It is about not losing important information we decided 10 years ago to keep
>>> in because otherwise, we’d have to sprinkle it across documents. And WE DID 
>>> decide to NOT create a third document.
>> 
>> AFAIR there was only consensus in having two documents.
>> I can live with two documents, but the content has to be clear. At this 
>> stage I do not consider its content clear enough.
> 
> Well you have to be specific where you think it is not clear.
> 
>> 
 The document can be shorter and to the point. There are a lot of OAM 
 information that does not belong to the data-plane.
>>> 
>>> The OAM information is necessary for the data-plane. And if LISP-GPE, 
>>> VXLAN, or any other data plane wants to use their own OAM or use the LISP 
>>> control-plane differently, it needs to be documented in their data-planes. 
>>> Hence, why this information is there.
>> 
>> Doesn’t make sense to me. That is not a reason. 
> 
> It is a reason, maybe one you don’t like, but it is a reason.
> 

The point is that in the current document there is a lot of OAM text that does 
not belong to the data-plane. 


>> That information can be available in another document and still be used by 
>> LISP-GPE, VxLAN, or any other data plane.
> 
> But we decided on only 2 documents. And if we put data-plane usage in a 
> control-plane document, then we are making 6833bis like 6830.
> 

We are better organising the specifications so that they are clearer and easier 
to read.


[snip]
> 
 You break the operational flow by opening a different point describing 
 what is what. It makes the overall procedure unclear.
>>> 
>>> It was put there because someone commented on it. You have to tell me why 
>>> you think it breaks flow. We discuss how end-systems send to EIDs. We say 
>>> what EIDs are and how they are assigned to hosts. And then we move to 
>>> RLOCs. It is pretty plan, simple, and straight-forward.
>>> 
>> 
>> Those two point would have more emphasis somewhere else. 
>> Where they are now they break the flow and do not provide details.
> 
> Unless you provide clear text where they should go, I’m not going to change 
> it.
> 

Suggested to merge with previous bullet in the reply to Albert.

>> You can actually put them at the end of section 1 as normal sentences. We 
>> then add a reference to LCAF and state that this document describes 
>> procedures only for EID that are IPv4 or IPv6 addresses.
> 
> The intro section is taking about broad concepts. Describing EIDs and RLOC 
> encodings is too early for it.

Is not encoding is the concept that and EID can be anything.
But if you do my previous suggestion it will work for me.


[snip]
>> In the ITR part we put as last bullet the first part of the original 
>> paragraph:
>> 
>>  - The Explicit Congestion Notification ('ECN’), namely bits  6 and 7 
>> of both the IPv4 and  IPv6 headers, requires special treatment
>>in order to avoid discarding indications of congestion [RFC3168].  An 
>> ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>header to the outer header.  Re-encapsulation MUST copy the 2-bit 
>> 'ECN' field from the stripped outer header to the new outer header.
>> 
>> 
>> In the ETR part we put as last bullet the second part of the original 
>> paragraph:
>> 
>>  - The Explicit Congestion Notification ('ECN’), namely bits  6 and 7 
>> of both the IPv4 and  IPv6 headers, requires special treatment
>>in order to avoid discarding indications of congestion [RFC3168].  If 
>> the 'ECN' field contains a congestion indication codepoint (the
>>value is '11', the Congestion Experienced (CE) codepoint), then 
>> ETR/PETR  decapsulation MUST copy the 2-bit 'ECN' field from
>>  the stripped outer header to the surviving inner header that is used to 
>> forward the  packet beyond the ETR.  
>> 
>> that’s it 
> 
> I made some minor comments but do not want to undo what David Black spent 
> effort on and got approval for. And I certainly don’t want to repeat text as 
> you suggested above.
> 

The text provided by Albert is very good, I will ask David to review the text 
again to make sure nothing has 

Re: [lisp] 6830bis Review

[Luigi Iannone]

HI Albert,

thanks for your reply. 

My comments inline. (trimming what is OK for me)

Luigi

> On 27 Dec 2017, at 02:48, Albert Cabellos  > wrote:
> 

[snip]
> >
> >
> >   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
> >  IPv6) value used in the source and destination address fields of
> >  the first (most inner) LISP header of a packet.  The host obtains
> >  a destination EID the same way it obtains a destination address
> >  today, for example, through a Domain Name System (DNS) [RFC1034]
> >  lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
> >  The source EID is obtained via existing mechanisms used to set a
> >  host's "local" IP address.  An EID used on the public Internet
> >  must have the same properties as any other IP address used in that
> >  manner; this means, among other things, that it must be globally
> >  unique.  An EID is allocated to a host from an EID-Prefix block
> >  associated with the site where the host is located.  An EID can be
> >  used by a host to refer to other hosts.  Note that EID blocks MAY
> >  be assigned in a hierarchical manner, independent of the network
> >  topology, to facilitate scaling of the mapping database.  In
> >  addition, an EID block assigned to a site may have site-local
> >  structure (subnetting) for routing within the site; this structure
> >  is not visible to the global routing system.  In theory, the bit
> >  string that represents an EID for one device can represent an RLOC
> >  for a different device.  As the architecture is realized, if a
> >  given bit string is both an RLOC and an EID, it must refer to the
> >  same entity in both cases.
> >
> >
> > Is the above sentence really necessary?
> >
> 
> Agreed, why not simplify the definitions. They are written from the ‘Internet 
> scalability mindset’, why not say that an EID is an address of the overlay 
> and an RLOC an address of the overlay. This change may require further 
> changes on the document so I am not 100% sure if this is a good idea.

For clarification I was just referring to the sentence:

 " As the architecture is realized, if a given bit string is both an RLOC and 
an EID, it must refer to the same entity in both cases.” 

I am wondering if such constrain is really necessary. If namespaces are well 
scoped there is no need for this. 

[snip]

About the following:

> 
> >
> >   o  EIDs are typically IP addresses assigned to hosts.
> >
> >   o  Other types of EID are supported by LISP, see [RFC8060] for
> >  further information.
> >
> > I would put the last two bullets in the definition of EID. It simplifies 
> > the story here.
> >
> >
> 
> I suggest to leave them here, I don´t think that readers start from the 
> ‘Definition of terms’, these are relevant concepts to understand LISP.

Good point about de definition of terms. What really bothers me is the bullet 
organisation. What can be done is to merge these two bullets with the previous 
one. 

> 
> >
> > The description of the encap/decap operation lacks of clarity concerning 
> > how to deal with
> > ECN bits and DSCP .
> >
> > 1. I think that the text should make explicitly the difference between DSCP 
> > and ECN fields.
> >
> > 2. How to deal with ECN should be part of the description of the  
> > encap/decap not a paragraph apart.
> >This basically means that half of the last paragraph should be a bullet 
> > of the ITR/PITR encapsulation
> >and the other half  in the ETR/PETR operation.
> 
> 
> Agreed, what about this (please comment):
> 
>When doing ITR/PITR encapsulation:
> 
> o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the 
> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
> o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or 
> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the 
> inner-header DSCP field ('Traffic Class' field, in the case of IPv6) 
> considering the exception listed below.
>o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the 
> IPv6 'Traffic Class' field) requires special treatment in order to avoid 
> discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy 
> the 2-bit 'ECN' field from the inner header to the outer header. 
> Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer 
> header to the new outer header.
> 
> When doing ETR/PETR decapsulation:
> 
>o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the 
> case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, 
> when the Time to Live value of the outer header is less than the Time to Live 
> value of the inner header.  Failing to perform this check can cause the Time 
> to Live of the inner header to increment across encapsulation/decapsulation 
> cycles.  This c

Re: [lisp] 6830bis Review

[Dino Farinacci]

> I would talk about that purely in terms of RLOCs being dervice from, and 
> assigned according to, the underlay.  It is up to the underlay to set it 
> policies so that it scales well (or chooses not to care, as some underlays 
> do.)


I can change “global Internet” to “core” and “provider underlay networks”. What 
do you think?

Dino

> 
> Yours,
> Joel
> 
> On 12/27/17 11:44 PM, Dino Farinacci wrote:
>>> Actually, I do not see why the LISP spec should talk at all about the 
>>> scalability of the underlay.  The underlay is what it is.  We are not 
>>> claiming to change that.
>> But if you assign non PA addresses to RLOCs, the underlay scalability will 
>> be worse. It’s definitely worth mentioning how EIDs are independent and can 
>> be opaque where RLOCs need to be topologically aggregatable, or otherise you 
>> worsen the underlay.
>> Dino
>>> Working Group:  Does anyone else have an opinion either way?  This document 
>>> belongs to the WG, not to the chairs or the editors.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/27/17 11:18 PM, Dino Farinacci wrote:
>> Note, we still care about scalability of any underlay, especially the 
>> Internet core, so we should leave this in. Note, we ARE still solving 
>> the scalability problem.
>> 
>> I don’t know why any of you would think differently.
> 
> We are solving this issue and many others. But the point of the document 
> is specifying a data-plane, not the benefits of this data-plane.
 When you spec a protocol you must say why you are doing it and ususally a 
 requirements for the solution state that. So benefits is a natural output 
 of satisfying the requirements. And at the same time we also indicate what 
 the costs are.
>> I have planned to remove the sentence.
>> 
>> What do you think about defining an EID as an identifier of the overlay 
>> and an RLOC as an identifier of the underlay? (Probably this needs to be 
>> reworded, but you get my point).
>> 
>> In my view this definition is broader and accounts for many of the LCAF 
>> uses.
 We spent two years on the definition of an EID and RLOC. There were so 
 many people that contributed and discussed it. Why undo that effort. There 
 is nothing inherently wrong with the definitions.
>> 
> I had planned to take Luigi’s suggestion. I did not want to rewrite this 
> section. It was carefully written by David Black with consolation from 
> the ECN experts. I do not want to lose this technical text.
> 
> I still think that Luigi's suggestion clarifies the text and that my edit 
> (hopefully) makes it easier for readers to understand. I just moved some 
> sentences .
 I made some changes but it is never a good idea to repeat the same exact 
 text. Check the new wording.
>>> Actually we should merge this section with 'Routing Locator Hashing’
>> 
>> I disagree with you guys. Who do you think punts packets when there is a 
>> map-cache miss? The data-plane. Note there are many users of the 
>> control-plane, an SDN controller, many data-planes, and lig/rig. How 
>> they each use the control-plane is documented in their own documents.
>> 
>> And please do not suggest that lig/rig usage of the control plane move 
>> to 6833bis.
>> 
> As an example, if we keep the 'Routing Locator Hashing' text as it is 
> then it only works with Map-Reply messages:
> 
> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that 
> is stored in the map-cache of a requesting ITR”
> 
>  The point is to allow LISP data-plane to work with any control-plane.
 No that has never been a requirement. We have stated (in the charter) that 
 we can use any data-plane “with the LISP control-plane”. We have never 
 discussed and it was never a requirement to do the converse.
 Dino
 ___
 lisp mailing list
 lisp@ietf.org
 https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Joel M. Halpern]

I would talk about that purely in terms of RLOCs being dervice from, and 
assigned according to, the underlay.  It is up to the underlay to set it 
policies so that it scales well (or chooses not to care, as some 
underlays do.)


Yours,
Joel

On 12/27/17 11:44 PM, Dino Farinacci wrote:

Actually, I do not see why the LISP spec should talk at all about the 
scalability of the underlay.  The underlay is what it is.  We are not claiming 
to change that.


But if you assign non PA addresses to RLOCs, the underlay scalability will be 
worse. It’s definitely worth mentioning how EIDs are independent and can be 
opaque where RLOCs need to be topologically aggregatable, or otherise you 
worsen the underlay.

Dino


Working Group:  Does anyone else have an opinion either way?  This document 
belongs to the WG, not to the chairs or the editors.

Yours,
Joel

On 12/27/17 11:18 PM, Dino Farinacci wrote:

Note, we still care about scalability of any underlay, especially the Internet 
core, so we should leave this in. Note, we ARE still solving the scalability 
problem.

I don’t know why any of you would think differently.


We are solving this issue and many others. But the point of the document is 
specifying a data-plane, not the benefits of this data-plane.

When you spec a protocol you must say why you are doing it and ususally a 
requirements for the solution state that. So benefits is a natural output of 
satisfying the requirements. And at the same time we also indicate what the 
costs are.

I have planned to remove the sentence.

What do you think about defining an EID as an identifier of the overlay and an 
RLOC as an identifier of the underlay? (Probably this needs to be reworded, but 
you get my point).

In my view this definition is broader and accounts for many of the LCAF uses.

We spent two years on the definition of an EID and RLOC. There were so many 
people that contributed and discussed it. Why undo that effort. There is 
nothing inherently wrong with the definitions.



I had planned to take Luigi’s suggestion. I did not want to rewrite this 
section. It was carefully written by David Black with consolation from the ECN 
experts. I do not want to lose this technical text.

I still think that Luigi's suggestion clarifies the text and that my edit 
(hopefully) makes it easier for readers to understand. I just moved some 
sentences .

I made some changes but it is never a good idea to repeat the same exact text. 
Check the new wording.

Actually we should merge this section with 'Routing Locator Hashing’


I disagree with you guys. Who do you think punts packets when there is a 
map-cache miss? The data-plane. Note there are many users of the control-plane, 
an SDN controller, many data-planes, and lig/rig. How they each use the 
control-plane is documented in their own documents.

And please do not suggest that lig/rig usage of the control plane move to 
6833bis.


As an example, if we keep the 'Routing Locator Hashing' text as it is then it 
only works with Map-Reply messages:

"When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is 
stored in the map-cache of a requesting ITR”

  The point is to allow LISP data-plane to work with any control-plane.

No that has never been a requirement. We have stated (in the charter) that we 
can use any data-plane “with the LISP control-plane”. We have never discussed 
and it was never a requirement to do the converse.
Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp





___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Dino Farinacci]

> Actually, I do not see why the LISP spec should talk at all about the 
> scalability of the underlay.  The underlay is what it is.  We are not 
> claiming to change that.

But if you assign non PA addresses to RLOCs, the underlay scalability will be 
worse. It’s definitely worth mentioning how EIDs are independent and can be 
opaque where RLOCs need to be topologically aggregatable, or otherise you 
worsen the underlay.

Dino

> Working Group:  Does anyone else have an opinion either way?  This document 
> belongs to the WG, not to the chairs or the editors.
> 
> Yours,
> Joel
> 
> On 12/27/17 11:18 PM, Dino Farinacci wrote:
 Note, we still care about scalability of any underlay, especially the 
 Internet core, so we should leave this in. Note, we ARE still solving the 
 scalability problem.
 
 I don’t know why any of you would think differently.
>>> 
>>> We are solving this issue and many others. But the point of the document is 
>>> specifying a data-plane, not the benefits of this data-plane.
>> When you spec a protocol you must say why you are doing it and ususally a 
>> requirements for the solution state that. So benefits is a natural output of 
>> satisfying the requirements. And at the same time we also indicate what the 
>> costs are.
 I have planned to remove the sentence.
 
 What do you think about defining an EID as an identifier of the overlay 
 and an RLOC as an identifier of the underlay? (Probably this needs to be 
 reworded, but you get my point).
 
 In my view this definition is broader and accounts for many of the LCAF 
 uses.
>> We spent two years on the definition of an EID and RLOC. There were so many 
>> people that contributed and discussed it. Why undo that effort. There is 
>> nothing inherently wrong with the definitions.
 
>>> I had planned to take Luigi’s suggestion. I did not want to rewrite this 
>>> section. It was carefully written by David Black with consolation from the 
>>> ECN experts. I do not want to lose this technical text.
>>> 
>>> I still think that Luigi's suggestion clarifies the text and that my edit 
>>> (hopefully) makes it easier for readers to understand. I just moved some 
>>> sentences .
>> I made some changes but it is never a good idea to repeat the same exact 
>> text. Check the new wording.
> Actually we should merge this section with 'Routing Locator Hashing’
 
 I disagree with you guys. Who do you think punts packets when there is a 
 map-cache miss? The data-plane. Note there are many users of the 
 control-plane, an SDN controller, many data-planes, and lig/rig. How they 
 each use the control-plane is documented in their own documents.
 
 And please do not suggest that lig/rig usage of the control plane move to 
 6833bis.
 
>>> As an example, if we keep the 'Routing Locator Hashing' text as it is then 
>>> it only works with Map-Reply messages:
>>> 
>>> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is 
>>> stored in the map-cache of a requesting ITR”
>>> 
>>>  The point is to allow LISP data-plane to work with any control-plane.
>> No that has never been a requirement. We have stated (in the charter) that 
>> we can use any data-plane “with the LISP control-plane”. We have never 
>> discussed and it was never a requirement to do the converse.
>> Dino
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review - control relationship

[Joel M. Halpern]

Trimmed...
I agree with Dino here.  There has never been a requirement that the 
LISP data plane work with anything other than the LISP control plane.


Strictly speaking, it is not even a requirement that the LISP control 
plane be capable of supporting anything other than the LISP data plane. 
However, we have found that to be useful, and so are going a short way 
down that path (there are still assumptions abou tthe data plane 
behavior that are needed for control plane robustness, which is fine.)


Yours,
Joel

On 12/27/17 11:18 PM, Dino Farinacci wrote:
...

Actually we should merge this section with 'Routing Locator Hashing’


I disagree with you guys. Who do you think punts packets when there is a 
map-cache miss? The data-plane. Note there are many users of the control-plane, 
an SDN controller, many data-planes, and lig/rig. How they each use the 
control-plane is documented in their own documents.

And please do not suggest that lig/rig usage of the control plane move to 
6833bis.


As an example, if we keep the 'Routing Locator Hashing' text as it is then it 
only works with Map-Reply messages:

"When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is 
stored in the map-cache of a requesting ITR”

  The point is to allow LISP data-plane to work with any control-plane.


No that has never been a requirement. We have stated (in the charter) that we 
can use any data-plane “with the LISP control-plane”. We have never discussed 
and it was never a requirement to do the converse.

Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Joel M. Halpern]

Actually, I do not see why the LISP spec should talk at all about the 
scalability of the underlay.  The underlay is what it is.  We are not 
claiming to change that.


Working Group:  Does anyone else have an opinion either way?  This 
document belongs to the WG, not to the chairs or the editors.


Yours,
Joel

On 12/27/17 11:18 PM, Dino Farinacci wrote:

Note, we still care about scalability of any underlay, especially the Internet 
core, so we should leave this in. Note, we ARE still solving the scalability 
problem.

I don’t know why any of you would think differently.


We are solving this issue and many others. But the point of the document is 
specifying a data-plane, not the benefits of this data-plane.


When you spec a protocol you must say why you are doing it and ususally a 
requirements for the solution state that. So benefits is a natural output of 
satisfying the requirements. And at the same time we also indicate what the 
costs are.



I have planned to remove the sentence.

What do you think about defining an EID as an identifier of the overlay and an 
RLOC as an identifier of the underlay? (Probably this needs to be reworded, but 
you get my point).

In my view this definition is broader and accounts for many of the LCAF uses.


We spent two years on the definition of an EID and RLOC. There were so many 
people that contributed and discussed it. Why undo that effort. There is 
nothing inherently wrong with the definitions.




I had planned to take Luigi’s suggestion. I did not want to rewrite this 
section. It was carefully written by David Black with consolation from the ECN 
experts. I do not want to lose this technical text.

I still think that Luigi's suggestion clarifies the text and that my edit 
(hopefully) makes it easier for readers to understand. I just moved some 
sentences .


I made some changes but it is never a good idea to repeat the same exact text. 
Check the new wording.


Actually we should merge this section with 'Routing Locator Hashing’


I disagree with you guys. Who do you think punts packets when there is a 
map-cache miss? The data-plane. Note there are many users of the control-plane, 
an SDN controller, many data-planes, and lig/rig. How they each use the 
control-plane is documented in their own documents.

And please do not suggest that lig/rig usage of the control plane move to 
6833bis.


As an example, if we keep the 'Routing Locator Hashing' text as it is then it 
only works with Map-Reply messages:

"When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is 
stored in the map-cache of a requesting ITR”

  The point is to allow LISP data-plane to work with any control-plane.


No that has never been a requirement. We have stated (in the charter) that we 
can use any data-plane “with the LISP control-plane”. We have never discussed 
and it was never a requirement to do the converse.

Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Dino Farinacci]

>> Note, we still care about scalability of any underlay, especially the 
>> Internet core, so we should leave this in. Note, we ARE still solving the 
>> scalability problem.
>> 
>> I don’t know why any of you would think differently.
> 
> We are solving this issue and many others. But the point of the document is 
> specifying a data-plane, not the benefits of this data-plane.

When you spec a protocol you must say why you are doing it and ususally a 
requirements for the solution state that. So benefits is a natural output of 
satisfying the requirements. And at the same time we also indicate what the 
costs are.


>> I have planned to remove the sentence.
>> 
>> What do you think about defining an EID as an identifier of the overlay and 
>> an RLOC as an identifier of the underlay? (Probably this needs to be 
>> reworded, but you get my point).
>> 
>> In my view this definition is broader and accounts for many of the LCAF uses.

We spent two years on the definition of an EID and RLOC. There were so many 
people that contributed and discussed it. Why undo that effort. There is 
nothing inherently wrong with the definitions.

> >
> I had planned to take Luigi’s suggestion. I did not want to rewrite this 
> section. It was carefully written by David Black with consolation from the 
> ECN experts. I do not want to lose this technical text.
> 
> I still think that Luigi's suggestion clarifies the text and that my edit 
> (hopefully) makes it easier for readers to understand. I just moved some 
> sentences . 

I made some changes but it is never a good idea to repeat the same exact text. 
Check the new wording.

>> > Actually we should merge this section with 'Routing Locator Hashing’
>> 
>> I disagree with you guys. Who do you think punts packets when there is a 
>> map-cache miss? The data-plane. Note there are many users of the 
>> control-plane, an SDN controller, many data-planes, and lig/rig. How they 
>> each use the control-plane is documented in their own documents.
>> 
>> And please do not suggest that lig/rig usage of the control plane move to 
>> 6833bis.
>> 
> As an example, if we keep the 'Routing Locator Hashing' text as it is then it 
> only works with Map-Reply messages:
> 
> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is 
> stored in the map-cache of a requesting ITR”
> 
>  The point is to allow LISP data-plane to work with any control-plane.

No that has never been a requirement. We have stated (in the charter) that we 
can use any data-plane “with the LISP control-plane”. We have never discussed 
and it was never a requirement to do the converse.

Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Albert Cabellos]

Hi all

Please find my comments inline:


On Wed, Dec 27, 2017 at 5:13 AM, Dino Farinacci  wrote:

> I will comment here before providing a new update and response to Luigi’s
> latest email.
>
> > On Dec 26, 2017, at 5:48 PM, Albert Cabellos 
> wrote:
> >
> > Hi
> >
> > Thanks for the review, please find my comments inline.
> >
> > I have removed all the comments for which I **agree**:
> >
> > >
> > >   Provider-Assigned (PA) Addresses:   PA addresses are an address block
> > >  assigned to a site by each service provider to which a site
> > >  connects.  Typically, each block is a sub-block of a service
> > >  provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
> > >  is aggregated into the larger block before being advertised into
> > >  the global Internet.  Traditionally, IP multihoming has been
> > >  implemented by each multihomed site acquiring its own globally
> > >  visible prefix.  LISP uses only topologically assigned and
> > >  aggregatable address blocks for RLOCs, eliminating this
> > >  demonstrably non-scalable practice.
> > >
> > > Last sentence to be deleted is a relic of scalability discussion.
> > >
> > >
> >
> > Agreed. I suggest deleting entirely the definitions for both PA and PI,
> they are not used throughout the document.
>
> Note, we still care about scalability of any underlay, especially the
> Internet core, so we should leave this in. Note, we ARE still solving the
> scalability problem.
>
> I don’t know why any of you would think differently.
>

We are solving this issue and many others. But the point of the document is
specifying a data-plane, not the benefits of this data-plane.


>
> >
> > [snip]
> > >
> > >
> > >   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
> > >  IPv6) value used in the source and destination address fields of
> > >  the first (most inner) LISP header of a packet.  The host obtains
> > >  a destination EID the same way it obtains a destination address
> > >  today, for example, through a Domain Name System (DNS) [RFC1034]
> > >  lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
> > >  The source EID is obtained via existing mechanisms used to set a
> > >  host's "local" IP address.  An EID used on the public Internet
> > >  must have the same properties as any other IP address used in that
> > >  manner; this means, among other things, that it must be globally
> > >  unique.  An EID is allocated to a host from an EID-Prefix block
> > >  associated with the site where the host is located.  An EID can be
> > >  used by a host to refer to other hosts.  Note that EID blocks MAY
> > >  be assigned in a hierarchical manner, independent of the network
> > >  topology, to facilitate scaling of the mapping database.  In
> > >  addition, an EID block assigned to a site may have site-local
> > >  structure (subnetting) for routing within the site; this structure
> > >  is not visible to the global routing system.  In theory, the bit
> > >  string that represents an EID for one device can represent an RLOC
> > >  for a different device.  As the architecture is realized, if a
> > >  given bit string is both an RLOC and an EID, it must refer to the
> > >  same entity in both cases.
> > >
> > >
> > > Is the above sentence really necessary?
> > >
> >
> > Agreed, why not simplify the definitions. They are written from the
> ‘Internet scalability mindset’, why not say that an EID is an address of
> the overlay and an RLOC an address of the overlay. This change may require
> further changes on the document so I am not 100% sure if this is a good
> idea.
>
> I have planned to remove the sentence.
>

What do you think about defining an EID as an identifier of the overlay and
an RLOC as an identifier of the underlay? (Probably this needs to be
reworded, but you get my point).

In my view this definition is broader and accounts for many of the LCAF
uses.


>
>
>
> >
> > >
> > > The description of the encap/decap operation lacks of clarity
> concerning how to deal with
> > > ECN bits and DSCP .
> > >
> > > 1. I think that the text should make explicitly the difference between
> DSCP and ECN fields.
> > >
> > > 2. How to deal with ECN should be part of the description of the
> encap/decap not a paragraph apart.
> > >This basically means that half of the last paragraph should be a
> bullet of the ITR/PITR encapsulation
> > >and the other half  in the ETR/PETR operation.
> >
> >
> > Agreed, what about this (please comment):
> >
> >When doing ITR/PITR encapsulation:
> >
> > o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in
> the case of IPv6) SHOULD be copied from the inner-header 'Time to Live'
> field.
> > o  The outer-header 'Differentiated Services Code Point' (DSCP)
> field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied
> from the inner-header DSCP 

Re: [lisp] 6830bis Review - scalability

[Dino Farinacci]

> Clearly, scalability of LISP matters.
> However, we are explicitly not attempting to move LISP to standards track for 
> purposes of solving global Internet address scaling problems. The agreement 
> under which we are doing this is to focus on the value of the other uses of 
> LISP.

Right, that is not the sole problem to solve. But removing the features of what 
overlays bring to the document would not be a good idea.

> To put it simply Dino, if we try to make the argument that LISP is suitable 
> for Internet-scale 

That is not what the text is saying. The text that people are commenting on is 
that the aggregatabeility of RLOC addresses should be present in the document.

> deployment, and for solving the core growth difficulties, we will have a 
> large set of additional arguments to undertake.  If we focus on what we have 
> agreed, we get Proposed Standards without having that fight.  And we get to 
> use a PS for all sorts of interesting and desirable tasks.

I agree that the document should not say we are trying to scale the Internet. 
And I believe it does not say that.

Dino

> 
> Yours,
> Joel
> 
> On 12/26/17 11:13 PM, Dino Farinacci wrote:
>> I will comment here before providing a new update and response to Luigi’s 
>> latest email.
>>> On Dec 26, 2017, at 5:48 PM, Albert Cabellos  
>>> wrote:
>>> 
>>> Hi
>>> 
>>> Thanks for the review, please find my comments inline.
>>> 
>>> I have removed all the comments for which I **agree**:
>>> 
 
   Provider-Assigned (PA) Addresses:   PA addresses are an address block
  assigned to a site by each service provider to which a site
  connects.  Typically, each block is a sub-block of a service
  provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
  is aggregated into the larger block before being advertised into
  the global Internet.  Traditionally, IP multihoming has been
  implemented by each multihomed site acquiring its own globally
  visible prefix.  LISP uses only topologically assigned and
  aggregatable address blocks for RLOCs, eliminating this
  demonstrably non-scalable practice.
 
 Last sentence to be deleted is a relic of scalability discussion.
 
 
>>> 
>>> Agreed. I suggest deleting entirely the definitions for both PA and PI, 
>>> they are not used throughout the document.
>> Note, we still care about scalability of any underlay, especially the 
>> Internet core, so we should leave this in. Note, we ARE still solving the 
>> scalability problem.
>> I don’t know why any of you would think differently.

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review - scalability

[Joel M. Halpern]

Clearly, scalability of LISP matters.
However, we are explicitly not attempting to move LISP to standards 
track for purposes of solving global Internet address scaling problems. 
The agreement under which we are doing this is to focus on the value of 
the other uses of LISP.


To put it simply Dino, if we try to make the argument that LISP is 
suitable for Internet-scale deployment, and for solving the core growth 
difficulties, we will have a large set of additional arguments to 
undertake.  If we focus on what we have agreed, we get Proposed 
Standards without having that fight.  And we get to use a PS for all 
sorts of interesting and desirable tasks.


Yours,
Joel

On 12/26/17 11:13 PM, Dino Farinacci wrote:

I will comment here before providing a new update and response to Luigi’s 
latest email.


On Dec 26, 2017, at 5:48 PM, Albert Cabellos  wrote:

Hi

Thanks for the review, please find my comments inline.

I have removed all the comments for which I **agree**:



   Provider-Assigned (PA) Addresses:   PA addresses are an address block
  assigned to a site by each service provider to which a site
  connects.  Typically, each block is a sub-block of a service
  provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
  is aggregated into the larger block before being advertised into
  the global Internet.  Traditionally, IP multihoming has been
  implemented by each multihomed site acquiring its own globally
  visible prefix.  LISP uses only topologically assigned and
  aggregatable address blocks for RLOCs, eliminating this
  demonstrably non-scalable practice.

Last sentence to be deleted is a relic of scalability discussion.




Agreed. I suggest deleting entirely the definitions for both PA and PI, they 
are not used throughout the document.


Note, we still care about scalability of any underlay, especially the Internet 
core, so we should leave this in. Note, we ARE still solving the scalability 
problem.

I don’t know why any of you would think differently.



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] 6830bis Review

[Dino Farinacci]

I will comment here before providing a new update and response to Luigi’s 
latest email.

> On Dec 26, 2017, at 5:48 PM, Albert Cabellos  
> wrote:
> 
> Hi
> 
> Thanks for the review, please find my comments inline.
> 
> I have removed all the comments for which I **agree**:
> 
> >
> >   Provider-Assigned (PA) Addresses:   PA addresses are an address block
> >  assigned to a site by each service provider to which a site
> >  connects.  Typically, each block is a sub-block of a service
> >  provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
> >  is aggregated into the larger block before being advertised into
> >  the global Internet.  Traditionally, IP multihoming has been
> >  implemented by each multihomed site acquiring its own globally
> >  visible prefix.  LISP uses only topologically assigned and
> >  aggregatable address blocks for RLOCs, eliminating this
> >  demonstrably non-scalable practice.
> >
> > Last sentence to be deleted is a relic of scalability discussion.
> >
> >
> 
> Agreed. I suggest deleting entirely the definitions for both PA and PI, they 
> are not used throughout the document.

Note, we still care about scalability of any underlay, especially the Internet 
core, so we should leave this in. Note, we ARE still solving the scalability 
problem.

I don’t know why any of you would think differently.

> 
> [snip]
> >
> >
> >   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
> >  IPv6) value used in the source and destination address fields of
> >  the first (most inner) LISP header of a packet.  The host obtains
> >  a destination EID the same way it obtains a destination address
> >  today, for example, through a Domain Name System (DNS) [RFC1034]
> >  lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
> >  The source EID is obtained via existing mechanisms used to set a
> >  host's "local" IP address.  An EID used on the public Internet
> >  must have the same properties as any other IP address used in that
> >  manner; this means, among other things, that it must be globally
> >  unique.  An EID is allocated to a host from an EID-Prefix block
> >  associated with the site where the host is located.  An EID can be
> >  used by a host to refer to other hosts.  Note that EID blocks MAY
> >  be assigned in a hierarchical manner, independent of the network
> >  topology, to facilitate scaling of the mapping database.  In
> >  addition, an EID block assigned to a site may have site-local
> >  structure (subnetting) for routing within the site; this structure
> >  is not visible to the global routing system.  In theory, the bit
> >  string that represents an EID for one device can represent an RLOC
> >  for a different device.  As the architecture is realized, if a
> >  given bit string is both an RLOC and an EID, it must refer to the
> >  same entity in both cases.
> >
> >
> > Is the above sentence really necessary?
> >
> 
> Agreed, why not simplify the definitions. They are written from the ‘Internet 
> scalability mindset’, why not say that an EID is an address of the overlay 
> and an RLOC an address of the overlay. This change may require further 
> changes on the document so I am not 100% sure if this is a good idea.

I have planned to remove the sentence.

> 
> [snip]
> >
> >   Re-encapsulating Tunneling in RTRs:   Re-encapsulating Tunneling
> >
> > RTR have never been defined.
> 
> 
> Agree, they are defined in LISP-TE, not sure about the rules here. They are 
> used in section 17.

No, it is used in this document. Others have made a comment that we referneced 
it but didn’t define it. RTRs were created BEFORE the LISP-TE draft was written.

> 

> 
> >
> > The description of the encap/decap operation lacks of clarity concerning 
> > how to deal with
> > ECN bits and DSCP .
> >
> > 1. I think that the text should make explicitly the difference between DSCP 
> > and ECN fields.
> >
> > 2. How to deal with ECN should be part of the description of the  
> > encap/decap not a paragraph apart.
> >This basically means that half of the last paragraph should be a bullet 
> > of the ITR/PITR encapsulation
> >and the other half  in the ETR/PETR operation.
> 
> 
> Agreed, what about this (please comment):
> 
>When doing ITR/PITR encapsulation:
> 
> o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the 
> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
> o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or 
> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the 
> inner-header DSCP field ('Traffic Class' field, in the case of IPv6) 
> considering the exception listed below.
>o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the 
> IPv6 'Traffic Class' field) requires special treatment in order to avoi

Re: [lisp] 6830bis Review

[Albert Cabellos]

Hi

Thanks for the review, please find my comments inline.

I have removed all the comments for which I **agree**:

>
>   Provider-Assigned (PA) Addresses:   PA addresses are an address block
>  assigned to a site by each service provider to which a site
>  connects.  Typically, each block is a sub-block of a service
>  provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
>  is aggregated into the larger block before being advertised into
>  the global Internet.  Traditionally, IP multihoming has been
>  implemented by each multihomed site acquiring its own globally
>  visible prefix.  LISP uses only topologically assigned and
>  aggregatable address blocks for RLOCs, eliminating this
>  demonstrably non-scalable practice.
>
> Last sentence to be deleted is a relic of scalability discussion.
>
>

Agreed. I suggest deleting entirely the definitions for both PA and PI,
they are not used throughout the document.

[snip]
>
>
>   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
>  IPv6) value used in the source and destination address fields of
>  the first (most inner) LISP header of a packet.  The host obtains
>  a destination EID the same way it obtains a destination address
>  today, for example, through a Domain Name System (DNS) [RFC1034]
>  lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
>  The source EID is obtained via existing mechanisms used to set a
>  host's "local" IP address.  An EID used on the public Internet
>  must have the same properties as any other IP address used in that
>  manner; this means, among other things, that it must be globally
>  unique.  An EID is allocated to a host from an EID-Prefix block
>  associated with the site where the host is located.  An EID can be
>  used by a host to refer to other hosts.  Note that EID blocks MAY
>  be assigned in a hierarchical manner, independent of the network
>  topology, to facilitate scaling of the mapping database.  In
>  addition, an EID block assigned to a site may have site-local
>  structure (subnetting) for routing within the site; this structure
>  is not visible to the global routing system.  In theory, the bit
>  string that represents an EID for one device can represent an RLOC
>  for a different device.  As the architecture is realized, if a
>  given bit string is both an RLOC and an EID, it must refer to the
>  same entity in both cases.
>
>
> Is the above sentence really necessary?
>

Agreed, why not simplify the definitions. They are written from the
‘Internet scalability mindset’, why not say that an EID is an address of
the overlay and an RLOC an address of the overlay. This change may require
further changes on the document so I am not 100% sure if this is a good
idea.

[snip]
>
>   Re-encapsulating Tunneling in RTRs:   Re-encapsulating Tunneling
>
> RTR have never been defined.


Agree, they are defined in LISP-TE, not sure about the rules here. They are
used in section 17.

[snip]
>
>   Recursive Tunneling:   Recursive Tunneling occurs when a packet has
>  more than one LISP IP header.  Additional layers of tunneling MAY
>  be employed to implement Traffic Engineering or other re-routing
>  as needed.  When this is done, an additional "outer" LISP header
>  is added, and the original RLOCs are preserved in the "inner"
>  header.
>
> Do not think the following sentence is really necessary.
>

It is an easy way to explain that tunnels can be nested, may be obvious for
us but not for some readers. In any case the term ‘recursive tunneling’ is
used several times throughout the document. I don´t have a strong opinion
but I´d say leave it as it is.

>
>   o  EIDs are typically IP addresses assigned to hosts.
>
>   o  Other types of EID are supported by LISP, see [RFC8060] for
>  further information.
>
> I would put the last two bullets in the definition of EID. It simplifies
the story here.
>
>

I suggest to leave them here, I don´t think that readers start from the
‘Definition of terms’, these are relevant concepts to understand LISP.

>
> The description of the encap/decap operation lacks of clarity concerning
how to deal with
> ECN bits and DSCP .
>
> 1. I think that the text should make explicitly the difference between
DSCP and ECN fields.
>
> 2. How to deal with ECN should be part of the description of the
 encap/decap not a paragraph apart.
>This basically means that half of the last paragraph should be a
bullet of the ITR/PITR encapsulation
>and the other half  in the ETR/PETR operation.


Agreed, what about this (please comment):

   When doing ITR/PITR encapsulation:

o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the
case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
o  The outer-header 'Differentiated Services Code Point' (DSCP) field
(or the 'Traffic Class' field, i

Re: [lisp] 6830bis Review (PLEASE COMMENTS)

[Luigi Iannone]

Dino,

my answers inline.

> On 18 Dec 2017, at 19:06, Dino Farinacci  wrote:
> 
>> Dino,
>> 
>> thanks for the hard work. 
> 
> I am trying to make it less harder than it needs to be. New diff and text 
> file enclosed.
> 
>> my replies inline (trimmed the points we agree or have been clarified by 
>> your answers).
> 
> Thanks for that.
> 
>> @ALL:   this is not a private discussion between me and Dino and I invite 
>> all of you to chime in and provide an opinion.
>> 
>> There one clear point here:  This document is not about data-plane, is 
>> data-plane + fragmented information that does not belong here. 
> 
> It is about not losing important information we decided 10 years ago to keep
> in because otherwise, we’d have to sprinkle it across documents. And WE DID 
> decide to NOT create a third document.

AFAIR there was only consensus in having two documents.
I can live with two documents, but the content has to be clear. At this stage I 
do not consider its content clear enough.


> 
>> The document can be shorter and to the point. There are a lot of OAM 
>> information that does not belong to the data-plane.
> 
> The OAM information is necessary for the data-plane. And if LISP-GPE, VXLAN, 
> or any other data plane wants to use their own OAM or use the LISP 
> control-plane differently, it needs to be documented in their data-planes. 
> Hence, why this information is there.

Doesn’t make sense to me. That is not a reason. 
That information can be available in another document and still be used by 
LISP-GPE, VxLAN, or any other data plane.

> 
> Short is not necessarily good if the document is incomplete.

Agreed, but long does not mean complete either.


 
 It is not alphabetical and not logical (at least I cannot se it).
>>> 
>>> Originally it was suppose to be logical. I will double check to make sure 
>>> the terms are introduced in an obvious sequence. If I can avoid 
>>> forward-references, I will do so.
>>> 
>> 
>> I guess this is still on your to do list. 
> 
> I thought the order was fine so I didn’t change it.
> 

OK, but a reader will just think the order is random. Can you add text 
elaborating the rationale of the order?


[snip]
> 
 
> Any references to tunnels in this specification refer to
>   dynamic encapsulating tunnels; they are never statically
>   configured.
>>> 
>>> Well many have said that LISP tunnels are not like traditional tunnels. 
>>> Traditional tunnels are configured and provisioned. Where LISP tunnels are 
>>> dynamic and used on demand. I would like the sectiond to stay.
>> 
>> You can move this sentence in the intro or where it make sense to you. In 
>> the Definition of terms is just lost.
> 
> I added it as the first definition in the Definition of Terms section.

Why not in the introduction or somewhere else? 
Why put a sentence that states what LISP is in the definition of term section? 
Such a sentence fits better in the introduction.


[snip]
>> 
> o  Other types of EID are supported by LISP, see [RFC8060] for
>   further information.
> 
 I would put the last two bullets in the definition of EID. It simplifies 
 the story here.
>>> 
>>> I think it should be kept in. I feel it adds value.
>> 
>> You break the operational flow by opening a different point describing what 
>> is what. It makes the overall procedure unclear.
> 
> It was put there because someone commented on it. You have to tell me why you 
> think it breaks flow. We discuss how end-systems send to EIDs. We say what 
> EIDs are and how they are assigned to hosts. And then we move to RLOCs. It is 
> pretty plan, simple, and straight-forward.
> 

Those two point would have more emphasis somewhere else. 
Where they are now they break the flow and do not provide details.

You can actually put them at the end of section 1 as normal sentences. We then 
add a reference to LCAF and state that this document describes procedures only 
for EID that are IPv4 or IPv6 addresses.

Incidentally, the end of the 1 section is also a good place to put the 
sentences about dynamic tunnelling. 


>> 
>> 
>>> 
> o  EID-Prefixes are likely to be hierarchically assigned in a manner
>   that is optimized for administrative convenience and to facilitate
>   scaling of the EID-to-RLOC mapping database.  The hierarchy is
>   based on an address allocation hierarchy that is independent of
>   the network topology.
> 
 Drop the last bullet it is about scalability.
>>> 
>>> Right, but still important to mention. Many of the benefits of LISP aren’t 
>>> always obvious. So we have to point them out.
>> 
>> Dino, this has to go away. This is NOT the control-plane advertisement 
>> document. This is the LISP control-plane, that’s all.
>> This was agreed upon at the time of rechartering.
> 
> Sorry disagree. You have to mention some control-plane. And not the 
> definition of it but how its used by this data-plane.
> 

The  bullet is just not accurate. Look at t

Re: [lisp] 6830bis Review (PLEASE COMMENTS)

[Luigi Iannone]

Dino,

thanks for the hard work. 
my replies inline (trimmed the points we agree or have been clarified by your 
answers).


@ALL:   this is not a private discussion between me and Dino and I invite all 
of you to chime in and provide an opinion.

There one clear point here:  This document is not about data-plane, is 
data-plane + fragmented information that does not belong here. 
The document can be shorter and to the point. There are a lot of OAM 
information that does not belong to the data-plane.


> On 17 Dec 2017, at 22:37, Dino Farinacci  wrote:
> 
>> Detailed comments inline.
> 
> Thanks for your comments. A diff and txt file are enclosed at the bottom.
> 
>> p.s. @Dino: sorry this is 07 version because I started with that version.
> 
> No worries.
> 
>> the wording “data-plane protocol” sounds awkward to me. I think would be 
>> better to put "data-plane operations” or even better “data-plane 
>> specifications”
>> Best solution: just drop it. This document describes the data plane of LISP. 
>>  
>> 
>> 
>>> for the Locator/ID
>>>  Separation Protocol (LISP).  LISP defines two namespaces, End-point
>>>  Identifiers (EIDs) that identify end-hosts and Routing Locators
>>>  (RLOCs) that identify network attachment points.  With this, LISP
>>>  effectively separates control from data, and allows routers to create
>>>  overlay networks.  LISP-capable routers exchange encapsulated packets
>>>  according to EID-to-RLOC mappings stored in a local map-cache.  The
>>>  map-cache is populated by the LISP Control-Plane protocol
>>> 
>> Same as above for the "control-plane protocol”
> 
> These are well-known terms across the industry. I would prefer to not change 
> them. Plus they made it through the experimental RFC-set without opposition.

It is redundant because the “P” in LISP that does mean “protocol”. But this is 
an english nit. I can live with the current wording.


> 
>>> 
>>> 3.  Definition of Terms
>>> 
>> 
>> What is the order of the Terms?
>> 
>> It is not alphabetical and not logical (at least I cannot se it).
> 
> Originally it was suppose to be logical. I will double check to make sure the 
> terms are introduced in an obvious sequence. If I can avoid 
> forward-references, I will do so.
> 

I guess this is still on your to do list. 


[snip]
> 
>>>  Re-encapsulating Tunneling in RTRs:   Re-encapsulating Tunneling
>>> 
>> RTR have never been defined.
> 
> It is being defined right here. I’ll read word it.
> 

If you define it the text should read like:

RTR: Re-encapsulating Tunnel Router…….


>>>  Recursive Tunneling:   Recursive Tunneling occurs when a packet has
>>> more than one LISP IP header.  Additional layers of tunneling MAY
>>> be employed to implement Traffic Engineering or other re-routing
>>> as needed.  When this is done, an additional "outer" LISP header
>>> is added, and the original RLOCs are preserved in the "inner"
>>> header.  
>>> 
>> Do not think the following sentence is really necessary.
>> 
>> 
>> 
>>> Any references to tunnels in this specification refer to
>>> dynamic encapsulating tunnels; they are never statically
>>> configured.
> 
> Well many have said that LISP tunnels are not like traditional tunnels. 
> Traditional tunnels are configured and provisioned. Where LISP tunnels are 
> dynamic and used on demand. I would like the sectiond to stay.

You can move this sentence in the intro or where it make sense to you. In the 
Definition of terms is just lost.

[snip]
> 
>>>  Server-side:  Server-side is a term used in this document to indicate
>>> that a connection initiation attempt is being accepted for a
>>> destination EID.  
>>> 
>> 
>> 
>> 
>> Rest of the paragraph not needed here. (it is specified in the operation 
>> part of the document)
>> 
>>> The ETR(s) at the destination LISP site may be
>>> the first to send Map-Replies to the source site initiating the
>>> connection.  The ETR(s) at this destination site can obtain
>>> mappings by gleaning information from Map-Requests, Data-Probes,
>>> or encapsulated packets.
> 
> Okay, reworded though.

Still not needed. And you added “MAY” which is pointless. Please delete. The 
procedures are described elsewhere in the document. 



> 
>>>  o  Other types of EID are supported by LISP, see [RFC8060] for
>>> further information.
>>> 
>> I would put the last two bullets in the definition of EID. It simplifies the 
>> story here.
> 
> I think it should be kept in. I feel it adds value.

You break the operational flow by opening a different point describing what is 
what. It makes the overall procedure unclear.


> 
>>>  o  EID-Prefixes are likely to be hierarchically assigned in a manner
>>> that is optimized for administrative convenience and to facilitate
>>> scaling of the EID-to-RLOC mapping database.  The hierarchy is
>>> based on an address allocation hierarchy that is independent of
>>> the network topology.
>>> 
>> Drop the last bullet it