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

[Albert Cabellos <[e-mail]>]

Hi all

I just posted -12 with the changes suggested by Luigi

Albert

On Tue, Mar 6, 2018 at 9:29 AM, Luigi Iannone <[e-mail]> wrote:

> 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>.
>
>
> [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>.
>
>
>
>
>
>
> 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]>
> wrote:
>
>> >> On 5 Mar 2018, at 19:06, Dino Farinacci <[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
>>
>>
>
>