Opened 9 years ago

Closed 9 years ago

#106 closed technical (fixed)

Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter)

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

Description

Section 6.1.4

ACT: This 3-bit field describes negative Map-Reply actions. These
bits are used only when the 'Locator Count' field is set to 0.
The action bits are encoded only in Map-Reply messages. The
actions defined are used by an ITR or PTR when a destination EID
matches a negative mapping cache entry. Unassigned values should
cause a map-cache entry to be created and, when packets match this
negative cache entry, they will be dropped. The current assigned

Why is this default chosen for unassigned actions? (This assumes that Create map-cache drop state is what is meant by "treat unassigned actions like action 0"). Since a three bit field was chosen, presumably the authors expect that up to eight different actions may be needed, but only three are defined.

How would the proposed default behavior affect whether such new flags can actually be deployed?

(1) Natively-Forward: The packet is not encapsulated or dropped

but natively forwarded.

Presumably "natively forwarded" means "forwarded without LISP encapsulation on the regular Internet topology"?

(2) Send-Map-Request: The packet invokes sending a Map-Request.

What does this mean?

Change History (2)

comment:1 Changed 9 years ago by yakov@…

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

comment:2 Changed 9 years ago by luigi@…

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