Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt

[Luigi Iannone <[e-mail]>]

Hi Albert,

thanks for submitting the updated document.

I have have a few residual nits listed below. Fixed those we can move to LC IMO.

Ciao

L.



> 
>    LISP Nonce:  The LISP 'Nonce' field is a 24-bit value that is
>       randomly generated by an ITR when the N-bit is set to 1.  Nonce
>       generation algorithms are an implementation matter but are
>       required to generate different nonces when sending to different
>       destinations.  
[Luigi]
As stated for -07: What is a destination? Should be different RLOCs, for clarity.


The Clock Sweep mechanism is just about management should go in AOM.


The following document are not Normative:

 [RFC4086 <>]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106 <https://tools.ietf.org/html/bcp106>, RFC 4086 <https://tools.ietf.org/html/rfc4086>,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086 <https://www.rfc-editor.org/info/rfc4086>>.

[RFC6275 <>]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275 <https://tools.ietf.org/html/rfc6275>, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275 <https://www.rfc-editor.org/info/rfc6275>>.





> On 5 Mar 2018, at 22:33, Albert Cabellos <[e-mail]> wrote:
> 
> Hi 
> 
> I'll post a new version without such sections shortly.
> 
> I volunteer to help writing the OAM document.
> 
> Albert
> 
> On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci <[e-mail] <mailto:[e-mail]>> wrote:
> >> On 5 Mar 2018, at 19:06, Dino Farinacci <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >>> Hi all
> >>>
> >>> This document should address all the comments except this one:
> >>>
> >>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement Considerations), 18 (Traceroute Consideration) to a new OAM document
> >>>
> >>> The authors would like to have a better understanding of where this text will go.
> >>
> >> Right, we concluded to not remove the valuable text.
> >
> > Nobody wants to lose valuable text.
> 
> Glad you feel that way.
> 
> >
> >> A lot of time and thought went into writing it and we didn’t want to lose it. There was no where that was agreed upon to put it.
> >
> > That is not accurate. There was clear indication to move it to a new OAM document, without any change in the text.
> > Purpose was to have just a different placeholder that make more sense.
> > This is an half an hour task.
> 
> But there was also concerns about slowing the process down. And the co-authors (Albert and I) don’t think it should move from RFC6833.
> 
> So there isn’t concensus. And I don’t believe it is even rough concensus.
> 
> >
> >>
> >> So since we felt there was no concensus on Sections 16-18, we didn’t make any change.
> >
> > Again not accurate, please spend half an hour to create the OAM document.
> > If you do not have time we can appoint other editors for the task. Authorship will be anyway preserved.
> 
> 
> Section 16 is “Mobility Considerations” that discusses various forms of how EIDs can change RLOCs. And it sets up for different designs that are already documented in various documents. But Mobility certainly shouldn’t go in an OAM document.
> 
> Section 17 discusses where xTRs (data-plane boxes) should reside in the network. And sets up for a more detail discussion which is in the Deployment RFC.
> 
> Section 18 is “Traceroute Considerations”, this arguably can go into an OAM document. But it would be 3 pages. And then one would argue there are other OAM mechanisms spread across LISP documents that could go in an OAM document.
> 
> This will not take 1/2 hour.
> 
> And I’m finding it hard to see the value in doing all this busy work. We have already accomplished separating data-plane text from control-plane text. We achieved that goal from the charter.
> 
> Dino
> 
>