> On Mar 19, 2018, at 6:22 PM, Dino Farinacci <[email protected]> wrote: > >> Dear WG, >> >> I did a quick review of rfc6833bis-08. Some comments/suggestions > > Thanks Victor. See new update enclosed. Let us know if you are good with the > changes and the response below. > >> 1. Section 5.8. Encapsulated Control Message Format. There is a reference to >> LH, it is not spelled out anywhere. I assume this means Lisp Header. > > It is a reference to the row in the diagram above: > > <PastedGraphic-16.png>
Understood, but should we not spell out LISP Header somewhere rather than just using LH without spelling it out anywhere? > > >> 2. Section 5.8. On page 27, there is a figure/header format showing the AD >> Type and Authentication Data Content, which is not referenced anywhere. >> Looks like it needs to be removed. > > Nice find. When the text was moved from RFC6830, we mis-placed it in RFC6833. Ack, good. > >> 3. Section 8.3/8.4. The text is limited to recommending exclusively a Native >> Forward action code. However the definition of the Map-reply message in >> section 5.4 allows 8 possible action codes and specifies 6 possible actions. >> If the WG agrees I can suggest text that would generalize the recommended >> processing behaviors described in 8.3 to allow the inclusion and use of the >> specified actions in the case of NMRs. > > Well the text below is correct and is explaining when a mapping entry DOES > NOT exist. For all other actions, they are sent for entries that DO EXIST in > the mapping database. And the reasons for sending the specific action type is > documented in the Map-Reply ACT field description: I agree that the text is correct, but I am pointing out that is not sufficient. If my policy is to drop traffic destined to an EID that is either not registered or not configured in the Mapping DB, how would I instruct the EID to drop the traffic? I would think I'd want to issue an NMR with action drop (4 or other). The spec currently doesn’t illustrate such actions. Text in 8.3 & 8.4 prescribes that the NMR for non-configured or non-registered EIDs will always have an action of Native-Forward, but I need the action to be Drop (for example). In the definitions section, the NMRs are defined as responses to queries for EIDs that DO NOT EXIST, in the text you pasted below, the ACT bits are defined as exclusive to the NMRs (set to 0 in any other message). It is not clear to me how these actions can apply to entries that DO EXIST? -v > > ACT: This 3-bit field describes Negative Map-Reply actions. In any > other message type, these bits are set to 0 and ignored on > receipt. 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 PITR when a > destination EID matches a negative Map-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 values are: > > (0) No-Action: The Map-Cache is kept alive, and no packet > encapsulation occurs. > > (1) Natively-Forward: The packet is not encapsulated or dropped > but natively forwarded. > > (2) Send-Map-Request: The packet invokes sending a Map-Request. > > (3) Drop/No-Reason: A packet that matches this Map-Cache entry is > dropped. An ICMP Destination Unreachable message SHOULD be > sent. > > (4) Drop/Policy-Denied: A packet that matches this Map-Cache > entry is dropped. The reason for the Drop action is that a > Map-Request for the target-EID is being policy denied by > either an xTR or the mapping system. > > (5) Drop/Authentication-Failure: A packet that matches this Map- > Cache entry is dropped. The reason for the Drop action is > that a Map-Request for the target-EID fails an authentication > verification-check by either an xTR or the mapping system. > > Thanks again, > Dino > > <rfcdiff.html> > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
