Subject: [lisp] #106: Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter)

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 28 Apr 2010 05:44:06 -0000

#106: Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 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?

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/106>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues