Re: [lisp] Fwd: AD Review of draft-ietf-lisp-6834bis-09

[Alvaro Retana <[e-mail]>]

On April 26, 2022 at 9:44:10 AM, Luigi Iannone wrote:

[Adding to the distribution list to keep everyone in the loop.]



Luigi:

Hi!

I have some replies below.

I'll take a look at the diffs when you post an update.


Thanks!

Alvaro.



...
> > > (1) Duplication and overlap
...
>
> [LI] Having a look to 6830bis:
> Yes, Section 13.2 can be dropped altogether. 6830bis references Section 13.2
> in Section 10 and Section 5.3. Both references can be replaced to a reference
> to 6834bis.
>
> As for the last two paragraphs: The very last is the text to be put in
> section 5.3.
>
> The second last is actually already present in the security section of
> 6834bis. This should be enough, right?
>
> I would just add the sentence “Further security considerations on
> Map-Versioning can be found in [6834bis]” in the paragraph mentioning
> Map-Versioning in Section 16 “Security Considerations” in 6833bis.

This sounds good to me.

As Shepherd for rfc6830bis, can you please take care of making sure
this update gets done?


> For 6833bis:
> In Section 5.4 replacing:
>
> Map-Version Number: When this 12-bit value is non-zero, the Map-
> Reply sender is informing the ITR what the version number is for
> the EID record contained in the Map-Reply. The ETR can allocate
> this number internally but MUST coordinate this value with other
> ETRs for the site. When this value is 0, there is no versioning
> information conveyed. The Map-Version Number can be included in
> Map-Request and Map-Register messages. See Map-Versioning
> [I-D.ietf-lisp-6834bis] for more details.
>
> With:
>
> Map-Version Number: 12-bit version number assigned to the EID
> record contained in the Map-Reply. See Map-Versioning
> [I-D.ietf-lisp-6834bis] for more details.
>
> The above should completely eliminate any duplication.

Yup.

Please also take care of this update.


...
> > 224 4.1. The Null Map-Version
> >
> > [] The comments below indicate that there are multiple places that
> > overlap with this section. The text from this section may be
> > relocated (and clarifying actions taken) to make the document clearer.
> > This section could then be eliminated.
> >
> > Paragraph 1 could be moved to §6.
> >
> > Paragraph 2 could be moved to §5/§5.1/§5.2.
> >
> > Paragraph 3 could be moved to §7.
> >
> > Paragraph 4 could be moved to §4.
...
>
>
> [LI] This is certainly a possible approach, but actually back to the writing
> of the original 6834, the section has been added in order to have one single
> place that specifies everything related to the null version number. If you
> really think that readability will have a huge improvement but spreading the
> content in other sections this can be done.

Yes, that's fine.


...
> > 262 5. Dealing with Map-Version Numbers
> > ...
> > 272 To each mapping, a version number is associated and changes each time
> > 273 the mapping is changed. Note that Map-Versioning does not introduce
> > 274 new problems concerning the coordination of different ETRs of a
> > 275 domain. Indeed, ETRs belonging to the same LISP site must return for
> > 276 a specific EID-prefix the same mapping, including the same Map-
> > 277 Version number. This is orthogonal to whether or not Map-Versioning
> > 278 is used. The synchronization problem and its implications on the
> > 279 traffic are out of the scope of this document.
> >
> > [] See my comment in §7 about leaving this out of scope and the
> > requirement from rfc6833bis.
>
>
> [LI] Not sure what is the issue here. This paragraph has been added in the
> first 6834 document because of the question “can different ETRs have
> different Map-Version for the same mapping” The answer is no. That text does
> not change anything in the 6833bis.

The text was cut before you got to §7. :-(