Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review

[luigi@…]

Section 6.2 introduces the terms client-side and server-side where are
these terms defined ? without such definition readability of the
section is low.

[luigi@…]

Yakov Rekhter raises a related question in his review of draft-ietf-lisp-06.txt (part 2):

Section 6.2

This section uses "client-side" and "server-side" extensively without
defining the terms. They seem to be the same as "ITR" and "ETR" in the
rest of the document. Terminology should be defined or harmonized with
the rest of the document.

[luigi@…]

Yakov Rekhter raises related editorial issues in his review of draft-ietf-lisp-06.txt (part 2):

Section 6.3.2

cached by the ITR or PTR. The ITR or PTR may include a mapping data
record for its own database mapping information.

What exactly is "its own database mapping information" ?

Section 6.4

Note that when a packet is LISP encapsulated, the source port number
in the outer UDP header needs to be set. Selecting a random value
allows core routers which are attached to Link Aggregation Groups
(LAGs) to load-split the encapsulated packets across member links of
such LAGs. Otherwise, core routers would see a single flow, since
packets have a source address of the ITR, for packets which are
originated by different EIDs at the source site. A suggested setting
for the source port number computed by an ITR is a 5-tuple hash
function on the inner header, as described above.

"Random" in the second sentence is contradicted by the last sentence.

Also, it is not clear why the paragraph restricts itself to talking
about LAGs. Load balancing is used plenty of other places.

Section 6.5

As a general comment, this section is in need of some editing to make
the prose more readable.

[luigi@…]

Replying to luigi@…:

This is part of Comment 26 of Rekhter's review

Yakov Rekhter raises a related question in his review of draft-ietf-lisp-06.txt (part 2):

Section 6.2

This section uses "client-side" and "server-side" extensively without
defining the terms. They seem to be the same as "ITR" and "ETR" in the
rest of the document. Terminology should be defined or harmonized with
the rest of the document.

[luigi@…]

Replying to luigi@…:

This is Comment 30 of Rekhter's review

Section 6.3.2

cached by the ITR or PTR. The ITR or PTR may include a mapping data
record for its own database mapping information.

What exactly is "its own database mapping information" ?

[luigi@…]

Replying to luigi@…:

This is Comment 31 of Rekhter's review

Section 6.4

Note that when a packet is LISP encapsulated, the source port number
in the outer UDP header needs to be set. Selecting a random value
allows core routers which are attached to Link Aggregation Groups
(LAGs) to load-split the encapsulated packets across member links of
such LAGs. Otherwise, core routers would see a single flow, since
packets have a source address of the ITR, for packets which are
originated by different EIDs at the source site. A suggested setting
for the source port number computed by an ITR is a 5-tuple hash
function on the inner header, as described above.

"Random" in the second sentence is contradicted by the last sentence.

Also, it is not clear why the paragraph restricts itself to talking
about LAGs. Load balancing is used plenty of other places.

[luigi@…]

Replying to luigi@…:

This is part of Comment 32 of Rekhter's review

Section 6.5

As a general comment, this section is in need of some editing to make
the prose more readable.