Opened 9 years ago

Closed 8 years ago

#70 closed technical (fixed)

Client not respecting RLOC weights (from Y. Rekhter's review)

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

Description (last modified by luigi@…)

This is part of Comment 26 of Rekhter's review

Section 6.2

Server-side returns a list of RLOC where a subset of the list has the
same best priority. Client can only use the subset list according to
the weighting assigned by the server-side.

If the client can gain some advantage (or thinks it can) by ignoring
the server's weighting, it will. There should be some consideration of
whether this is a problem, and if so, how to address it.

Change History (7)

comment:1 Changed 9 years ago by luigi@…

  • Description modified (diff)

comment:2 Changed 9 years ago by luigi@…

  • Resolution set to fixed
  • Status changed from new to resolved

Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion.

comment:3 Changed 9 years ago by luigi@…

  • Status changed from resolved to closed

comment:4 Changed 9 years ago by yakov@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

The issue raised in this ticket is still not addressed. Thus the ticket must stay open.

comment:5 Changed 9 years ago by yakov@…

Here is from the response to my original comment:

Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors
have reviewed your comments but do not feel that changes to the document are
warranted at this time. Implementations must adhere to the specification.

Note that the text I quoted above uses none of the ""MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL". So, the text still does not say what is exactly required by the specification. Thus the spec has to replace "can" in "Client can only.." with one of the terms defined in rfc2119.


comment:6 Changed 8 years ago by luigi@…

  • Resolution set to fixed
  • Status changed from reopened to resolved

The issue has been fixed in version -12 of the draft as described in section B.1:

  • Tracker item 70. Added text to security section on what the implications could be if an ITR does not obey priority and weights from a Map-Reply message.

comment:7 Changed 8 years ago by luigi@…

  • Status changed from resolved to closed
Note: See TracTickets for help on using tickets.