Re: [lisp] Confirm/Deny changes on draft 6830bis

[Dino Farinacci <[e-mail]>]

Thanks for the detail review Padma. A new update to -09 is enclosed with a diff file. I will wait until next week to post.

I have reflected all of your comments and most of Luigi’s comments. The only issues open are:

(1) Section movement from RFC6830 to RFC6833.

(2) If an OAM document is needed.

Waiting for more working group concensus on this.

> Dear Dino and Albert 
> 
> The doc reads well.
> Please find thereafter some comments on the version- 09 you posted on the list 
> 
> Page 4
> "Client-side:  Client-side is a term used in this document to indicate a connection initiation attempt by an EID."
> PPE 1: Strictly speaking the EID is just an identifier and does not initiate anything. Suggest something like this.
> 
> "Client-side:  Client-side is a term used in this document to indicate a connection initiation attempt by the end system (represented by an EID)”

Fixed. Put in your suggestion.

> Page 6
> The source EID is obtained via existing mechanisms used to set a host's "local" IP address.  An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique.
> 
> PPE 2: Shouldn't these two be MUST rather than must? Suggestion below
> 
> The source EID is obtained via existing mechanisms used to set a host's "local" IP address.  An EID used on the public Internet MUST have the same properties as any other IP address used in that manner; this means, among other things, that it MUST be globally unique.

Changed.

> Page 8
> An EID maps to one or more RLOCs.
> PPE 3: Seems to contradict earlier explanation on negative mapping entry where it is possible that an EID has NO RLOC.

I changed to “zero or more RLOCs.”.

> Page 8 
> When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration.
> 
> PPE 4: Suggest to add "re-encapsulation" in the list in Security Considerations section as this is an exploit possibility.

I have removed the sentence. Because it actually is not true. If you use different mapping systems and circuitious forwarding occurs. The packet travels only until its TTL reaches 0. Using the rules for copy inner to outer and outer to inner during RTR re-encapsulation applies.

> Page 13
> "gleaned" mapping
> 
> PPE 5: Suggest adding “glean mapping” in the definition section.

Changed.

> Page 17
> "The KK-bits are a 2-bit field used when encapsualted packets are encrypted."
> 
> PPE 6: Nit - Typo "encapsualted" -> “encapsulated"

Fixed.

> 
> Page 20
> "When the lookup succeeds, the locator-set  retrieved from the map-cache is used to send the packet to the EID's topological location."
> 
> PPE 7: Nit - Suggest capitalize L and S of "locator-set" for consistency with rest of document.

Thanks. Done.

> 
> Page 23
> "The server-side sets a Weight of 0..."
> PPE 8: Nit - For consistency in text change to "Weight of zero”.

Changed.

> Page 23 
> "Control is shared by the server- side determining the list and the client determining load  distribution." 
> 
> PPE 9: Suggest use of "Client-side"
> 
> "Control is shared by the server- side determining the list and the client-side determining load distribution.”

Done.

> Page 24
> When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches
> the EID-Prefix of the verified entry.[PE1]   This "gleaning" mechanism is OPTIONAL.
> 
> PPE 10: In section 16.2 later gleaning is used as a solution.  Changes in the gleaned info could be an interesting way to update the cache fast …however this text make it sound that this is not an option after first packet.

It is an option when the ETR has no mapping to return packets. Once a mapping is cache, there is no point to glean since the mapping system verified the information the same as in the map-cache.

>   
> Page 25
> "Note that trusting ICMP messages may  not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions."
> 
> PPE 11: A reference would be useful if possible.

Added draft-ietf-opsec-icmp-filtering.

> Page 25
> "An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address."
> 
> PPE 12: Isn't this true for any protocol entry not just a BGP entry? We are really trying to determine if there is no route whatever the protocol.

Yes, we can generalize this. I changed text.

> Page 38
> "For a more detailed networkd design deployment recommendation, refer to [RFC7215]."
> 
> PPE 13: Nit typo "netword"-> “network"

Changed.

> Page 40
> "By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new encapsuluation path to the destination end site."
> 
> PPE 14: Nit Typo "encapsuluation" -> “encapsulation"

Changed.

> Page 43
> "If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim;s RLOC, potentially overloading it."
> 

> PPE 15: Nit  typo "victim;s" -> “victim’s”

Changed.

Dino