Re: [lisp] Current changes for draft-ietf-lisp-rfc6830bis-08

[Luigi Iannone]

Hi Albert,


> On 9 Jan 2018, at 00:27, Albert Cabellos  wrote:
> 
> Hi 
> 
> As far as I remember we didn´t agree on 3 documents, this does not 
> necessarily mean that it is a bad idea.

:-)

> 
> I still think that SMR should be on 6833bis, it is important to standardize a 
> control-plane that includes the capability of updating EID-to-RLOC mappings.
> 
> Regarding sections Multicast, Mobility and Traceroute considerations they 
> could be easily moved to an OAM document, but it is quite complex to properly 
> contextualize such sections in a single standalone document. Do they have 
> value without the context of 6830bis?

Probably not, but the point is that if you implement 6830bis you do need to 
read OAM stuff. 

Obviously the other way around is not true. If you want to understand LISP OAM 
you need to have a good knowledge of both 30bis _AND_ 33bis, _YET_ this does 
_NOT_ mean we need one single document for everything.

Romans used to say "dividi et impera”…. 

Ciao

Luigi


> In my view they are better in 6830bis.
> 
> I would like to hear other opinions from the list
> 
> Albert
> 
> On Mon, Jan 8, 2018 at 7:22 PM, Dino Farinacci  > wrote:
> Do you think it is okay to capture the changes we have made and agreed upon 
> so far so we can submit -08 and wait for other WG members to comment on this 
> issue?
> 
> What you are suggesting is a lot change that what was previously agreed upon. 
> No one was really in favor of having a third document (your OAM reference 
> below (3)).
> 
> Also the chairs didn’t suggest any changes, it was Luigi (acting as a 
> document shepherd). I am not sure the same comment came from Joel, either 
> publicly or privately.
> 
> Dino
> 
> > On Jan 8, 2018, at 9:16 AM, Damien Saucez  > > wrote:
> >
> > Hello Dino, The List,
> >
> > That’s pretty cool to see activity around the document however I am not 
> > sure the proposed
> > changes are really addressing the structural problem of the document.
> >
> > The current document is a mix between data-plane, control-plane, and 
> > operation questions.
> >
> > The chairs proposition of re-balancing the text between 30bis, 33bis and an 
> > OAM documents
> > is great. It would allow people to go directly to the point they are 
> > interested in.
> >
> > 1. What goes on the wire: 30bis
> > 2. Signalling procedures: 33bis
> > 3. Implementation details, management, and troubleshooting: OAM.
> >
> > So it would mean that in 30bis it would just be all what is strictly needed 
> > to allow
> > inter-operability between xTRs, so at the end only packet format and how to 
> > understand
> > fields should be there. In this case, we can abstract the xTR as just a 
> > database that
> > stores mapping, how mapping are managed in this database is an 
> > implementation
> > question that is independent of the protocol itself.
> >
> > For 33bis, it would just be the format of signalling messages and how to 
> > interpret
> > them, when a signal is expected to be triggered.
> >
> > Finally, in OAM it would be how to implement and manage a LISP system that 
> > is
> > constituted of the LISP control-plane proposed in 33bis and the LISP 
> > data-plane in
> > 30bis.
> >
> > To say it clearly: remove from 30bis and 33bis all what is just the reflect 
> > of one
> > implementation. Normally these two document should have only what is 
> > strictly
> > necessary for people to implement (the way THEY want) a system that would
> > Inter-operate with the others.
> >
> > If we look at OpenLISP and its control-plane and the deployment of LISP-Lab
> > that we use in production daily, we can see that the data plane and control 
> > plane
> > have been implemented independently (and by different teams and even
> > companies) and what we can say is that a large fraction of the text in 60bis
> > has not been used at all for implementing the data-plane, while, on the 
> > contrary
> > we had to massively read/use text from 30bis to be able to implement the
> > control-plane. Finally, people that deployed LISP-Lab had to take content
> > from both 30bis and 33bis to be able to have a working environment. That
> > demonstrates that the separation is not done properly as normally people
> > in charge of deploying a network should not have to read the data-plane
> > specs, or people implementing a control-plane should not have to read
> > data-plane specifications.
> >
> > I think the proposition of moving text that the chairs proposed is very
> > reasonable and greatly improve the quality of the specifications and 
> > therefore
> > reduce the risk of misinterpretation and bugs while implementing the 
> > protocolS
> >
> >
> > Cheers,
> >
> > Damien Saucez
> >
> >> On 4 Jan 2018, at 18:00, Dino Farinacci  >> > wrote:
> >>
> >> Is the working group okay with me submitting these changes? This was the 
> >> latest update from email before the year ended. I have made most of

Re: [lisp] Current changes for draft-ietf-lisp-rfc6830bis-08

[Albert Cabellos]

Hi


As far as I remember we didn´t agree on 3 documents, this does not
necessarily mean that it is a bad idea.


I still think that SMR should be on 6833bis, it is important to standardize
a control-plane that includes the capability of updating EID-to-RLOC
mappings.


Regarding sections Multicast, Mobility and Traceroute considerations they
could be easily moved to an OAM document, but it is quite complex to
properly contextualize such sections in a single standalone document. Do
they have value without the context of 6830bis? In my view they are better
in 6830bis.


I would like to hear other opinions from the list


Albert

On Mon, Jan 8, 2018 at 7:22 PM, Dino Farinacci  wrote:

> Do you think it is okay to capture the changes we have made and agreed
> upon so far so we can submit -08 and wait for other WG members to comment
> on this issue?
>
> What you are suggesting is a lot change that what was previously agreed
> upon. No one was really in favor of having a third document (your OAM
> reference below (3)).
>
> Also the chairs didn’t suggest any changes, it was Luigi (acting as a
> document shepherd). I am not sure the same comment came from Joel, either
> publicly or privately.
>
> Dino
>
> > On Jan 8, 2018, at 9:16 AM, Damien Saucez 
> wrote:
> >
> > Hello Dino, The List,
> >
> > That’s pretty cool to see activity around the document however I am not
> sure the proposed
> > changes are really addressing the structural problem of the document.
> >
> > The current document is a mix between data-plane, control-plane, and
> operation questions.
> >
> > The chairs proposition of re-balancing the text between 30bis, 33bis and
> an OAM documents
> > is great. It would allow people to go directly to the point they are
> interested in.
> >
> > 1. What goes on the wire: 30bis
> > 2. Signalling procedures: 33bis
> > 3. Implementation details, management, and troubleshooting: OAM.
> >
> > So it would mean that in 30bis it would just be all what is strictly
> needed to allow
> > inter-operability between xTRs, so at the end only packet format and how
> to understand
> > fields should be there. In this case, we can abstract the xTR as just a
> database that
> > stores mapping, how mapping are managed in this database is an
> implementation
> > question that is independent of the protocol itself.
> >
> > For 33bis, it would just be the format of signalling messages and how to
> interpret
> > them, when a signal is expected to be triggered.
> >
> > Finally, in OAM it would be how to implement and manage a LISP system
> that is
> > constituted of the LISP control-plane proposed in 33bis and the LISP
> data-plane in
> > 30bis.
> >
> > To say it clearly: remove from 30bis and 33bis all what is just the
> reflect of one
> > implementation. Normally these two document should have only what is
> strictly
> > necessary for people to implement (the way THEY want) a system that would
> > Inter-operate with the others.
> >
> > If we look at OpenLISP and its control-plane and the deployment of
> LISP-Lab
> > that we use in production daily, we can see that the data plane and
> control plane
> > have been implemented independently (and by different teams and even
> > companies) and what we can say is that a large fraction of the text in
> 60bis
> > has not been used at all for implementing the data-plane, while, on the
> contrary
> > we had to massively read/use text from 30bis to be able to implement the
> > control-plane. Finally, people that deployed LISP-Lab had to take content
> > from both 30bis and 33bis to be able to have a working environment. That
> > demonstrates that the separation is not done properly as normally people
> > in charge of deploying a network should not have to read the data-plane
> > specs, or people implementing a control-plane should not have to read
> > data-plane specifications.
> >
> > I think the proposition of moving text that the chairs proposed is very
> > reasonable and greatly improve the quality of the specifications and
> therefore
> > reduce the risk of misinterpretation and bugs while implementing the
> protocolS
> >
> >
> > Cheers,
> >
> > Damien Saucez
> >
> >> On 4 Jan 2018, at 18:00, Dino Farinacci  wrote:
> >>
> >> Is the working group okay with me submitting these changes? This was
> the latest update from email before the year ended. I have made most of the
> changes that Luigi suggested or requested.
> >>
> >> 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
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Current changes for draft-ietf-lisp-rfc6830bis-08

[Dino Farinacci]

Do you think it is okay to capture the changes we have made and agreed upon so 
far so we can submit -08 and wait for other WG members to comment on this issue?

What you are suggesting is a lot change that what was previously agreed upon. 
No one was really in favor of having a third document (your OAM reference below 
(3)). 

Also the chairs didn’t suggest any changes, it was Luigi (acting as a document 
shepherd). I am not sure the same comment came from Joel, either publicly or 
privately.

Dino

> On Jan 8, 2018, at 9:16 AM, Damien Saucez  wrote:
> 
> Hello Dino, The List,
> 
> That’s pretty cool to see activity around the document however I am not sure 
> the proposed
> changes are really addressing the structural problem of the document.
> 
> The current document is a mix between data-plane, control-plane, and 
> operation questions.
> 
> The chairs proposition of re-balancing the text between 30bis, 33bis and an 
> OAM documents
> is great. It would allow people to go directly to the point they are 
> interested in. 
> 
> 1. What goes on the wire: 30bis
> 2. Signalling procedures: 33bis
> 3. Implementation details, management, and troubleshooting: OAM.
> 
> So it would mean that in 30bis it would just be all what is strictly needed 
> to allow
> inter-operability between xTRs, so at the end only packet format and how to 
> understand
> fields should be there. In this case, we can abstract the xTR as just a 
> database that
> stores mapping, how mapping are managed in this database is an implementation
> question that is independent of the protocol itself.
> 
> For 33bis, it would just be the format of signalling messages and how to 
> interpret
> them, when a signal is expected to be triggered.
> 
> Finally, in OAM it would be how to implement and manage a LISP system that is
> constituted of the LISP control-plane proposed in 33bis and the LISP 
> data-plane in
> 30bis.
> 
> To say it clearly: remove from 30bis and 33bis all what is just the reflect 
> of one
> implementation. Normally these two document should have only what is strictly
> necessary for people to implement (the way THEY want) a system that would
> Inter-operate with the others. 
> 
> If we look at OpenLISP and its control-plane and the deployment of LISP-Lab
> that we use in production daily, we can see that the data plane and control 
> plane
> have been implemented independently (and by different teams and even
> companies) and what we can say is that a large fraction of the text in 60bis
> has not been used at all for implementing the data-plane, while, on the 
> contrary
> we had to massively read/use text from 30bis to be able to implement the
> control-plane. Finally, people that deployed LISP-Lab had to take content
> from both 30bis and 33bis to be able to have a working environment. That
> demonstrates that the separation is not done properly as normally people 
> in charge of deploying a network should not have to read the data-plane
> specs, or people implementing a control-plane should not have to read 
> data-plane specifications.
> 
> I think the proposition of moving text that the chairs proposed is very
> reasonable and greatly improve the quality of the specifications and therefore
> reduce the risk of misinterpretation and bugs while implementing the protocolS
> 
> 
> Cheers,
> 
> Damien Saucez 
> 
>> On 4 Jan 2018, at 18:00, Dino Farinacci  wrote:
>> 
>> Is the working group okay with me submitting these changes? This was the 
>> latest update from email before the year ended. I have made most of the 
>> changes that Luigi suggested or requested.
>> 
>> 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] Current changes for draft-ietf-lisp-rfc6830bis-08

[Damien Saucez]

Hello Dino, The List,

That’s pretty cool to see activity around the document however I am not sure 
the proposed
changes are really addressing the structural problem of the document.

The current document is a mix between data-plane, control-plane, and operation 
questions.

The chairs proposition of re-balancing the text between 30bis, 33bis and an OAM 
documents
is great. It would allow people to go directly to the point they are interested 
in. 

1. What goes on the wire: 30bis
2. Signalling procedures: 33bis
3. Implementation details, management, and troubleshooting: OAM.

So it would mean that in 30bis it would just be all what is strictly needed to 
allow
inter-operability between xTRs, so at the end only packet format and how to 
understand
fields should be there. In this case, we can abstract the xTR as just a 
database that
stores mapping, how mapping are managed in this database is an implementation
question that is independent of the protocol itself.

For 33bis, it would just be the format of signalling messages and how to 
interpret
them, when a signal is expected to be triggered.

Finally, in OAM it would be how to implement and manage a LISP system that is
constituted of the LISP control-plane proposed in 33bis and the LISP data-plane 
in
30bis.

To say it clearly: remove from 30bis and 33bis all what is just the reflect of 
one
implementation. Normally these two document should have only what is strictly
necessary for people to implement (the way THEY want) a system that would
Inter-operate with the others. 

If we look at OpenLISP and its control-plane and the deployment of LISP-Lab
that we use in production daily, we can see that the data plane and control 
plane
have been implemented independently (and by different teams and even
companies) and what we can say is that a large fraction of the text in 60bis
has not been used at all for implementing the data-plane, while, on the contrary
we had to massively read/use text from 30bis to be able to implement the
control-plane. Finally, people that deployed LISP-Lab had to take content
from both 30bis and 33bis to be able to have a working environment. That
demonstrates that the separation is not done properly as normally people 
in charge of deploying a network should not have to read the data-plane
specs, or people implementing a control-plane should not have to read 
data-plane specifications.

I think the proposition of moving text that the chairs proposed is very
reasonable and greatly improve the quality of the specifications and therefore
reduce the risk of misinterpretation and bugs while implementing the protocolS


Cheers,

Damien Saucez 

> On 4 Jan 2018, at 18:00, Dino Farinacci  wrote:
> 
> Is the working group okay with me submitting these changes? This was the 
> latest update from email before the year ended. I have made most of the 
> changes that Luigi suggested or requested.
> 
> 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