Opened 9 years ago

Last modified 9 years ago

#32 new editorial

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

Reported by: luigi@… Owned by:
Priority: trivial Component: draft-ietf-lisp
Severity: - Keywords:
Cc:

Description (last modified by 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.

Change History (6)

comment:1 follow-up: Changed 9 years ago by 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.

comment:2 follow-ups: Changed 9 years ago by luigi@…

  • Description modified (diff)

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.

comment:3 in reply to: ↑ 1 Changed 9 years ago by 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.

comment:4 in reply to: ↑ 2 Changed 9 years ago by 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" ?

comment:5 in reply to: ↑ 2 Changed 9 years ago by 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.

comment:6 in reply to: ↑ 2 Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.