Note A and C are addressed in the -09 revision I sent out in Friday. Dino
> On Jan 28, 2018, at 5:57 PM, Albert Cabellos <[email protected]> > wrote: > > Hi all > > Thanks for all the comments, from my understanding of this thread the > following list of items *seem* to have rough consensus (all except B - change > definitions for EID and RLOC). > > Joel, Luigi->How should we proceed now? > > Albert > > --- > > A.- Remove definitions of PA and PI > > C.- In section 5.3, change the description of the encap/decap operation > concerning how to deal with ECN and DSCP bits to (new text needs to be > validated by experts): > > When doing ITR/PITR encapsulation: > > o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case > of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. > > o The outer-header 'Differentiated Services Code Point' (DSCP) field (or the > 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the > inner-header DSCP field ('Traffic Class' field, in the case of IPv6) > considering the exception listed below. > > o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the > IPv6 'Traffic Class' field) requires special treatment in order to avoid > discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy > the 2-bit 'ECN' field from the inner header to the outer header. > Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer > header to the new outer header. > > When doing ETR/PETR decapsulation: > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case > of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when > the Time to Live value of the outer header is less than the Time to Live > value of the inner header. Failing to perform this check can cause the Time > to Live of the inner header to increment across encapsulation/decapsulation > cycles. This check is also performed when doing initial encapsulation, when > a packet comes to an ITR or PITR destined for a LISP site. > > o The inner-header 'Differentiated Services Code Point' (DSCP) field (or the > 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the > outer-header DSCP field ('Traffic Class' field, in the case of IPv6) > considering the exception listed below. > > o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the > IPv6 'Traffic Class' field) requires special treatment in order to avoid > discarding indications of congestion [RFC3168]. If the 'ECN' field contains a > congestion indication codepoint (the value is '11', the Congestion > Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' > field from the stripped outer header to the surviving inner header that is > used to forward the packet beyond the ETR. These requirements preserve CE > indications when a packet that uses ECN traverses a LISP tunnel and becomes > marked with a CE indication due to congestion between the tunnel endpoints. > > Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate > after decapsulating, the net effect of this is that the new outer header will > carry the same Time to Live as the old outer header minus 1. > > Copying the Time to Live (TTL) serves two purposes: first, it preserves the > distance the host intended the packet to travel; second, and more > importantly, it provides for suppression of looping packets in the event > there is a loop of concatenated tunnels due to misconfiguration. See Section > 18.3 for TTL exception handling for traceroute packets. > > D.- Simplify section ‘Router Locator Selection’ stating that the data-plane > MUST follow what´s stored in the map-cache (priorities and weights), the > remaining text should go to an OAM document. > > E.- Rewrite Section “Routing Locator Reachability” considering the following > changes: > > * Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and > Echo-Nonce > * Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3 (hints > from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a response) and > RLOC probing > > F.- Move Solicit-Map-Request to 6833bis > > G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement > Considerations), 18 (Traceroute Consideration) to a new OAM document > >> On Fri, Jan 26, 2018 at 8:20 PM, Dino Farinacci <[email protected]> wrote: >> 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 >> >> >> >> >> >> >> >> >> >> >> >> >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
