Fixing the simple issues first. Clipping out the rest of the text.
> Is there anything different between an "EID-to-RLOC Map-Request" and just a
> "Map-Request"? (Same question for "Map-Reply", too.)
No. But Map-Requests are used for lookups in the mapping system as well as for
probing RLOCs for reachability.
> Section 3
>
> nit: "An address family that pertains to the Data-Plane." is a sentence
> fragment.
Fixed.
>
> Ingress Tunnel Router (ITR): An ITR is a router that resides in a
> [...]
> mapping lookup in the destination address field. Note that this
> destination RLOC MAY be an intermediate, proxy device that has
> better knowledge of the EID-to-RLOC mapping closer to the
>
> This doesn't seem like a 2119 MAY is necessary, but rather a statement of
> fact that may not be known to the encapsulating ITR.
Agree. Fixed.
>
> Specifically, when a service provider prepends a LISP header for
> Traffic Engineering purposes, the router that does this is also
> regarded as an ITR. The outer RLOC the ISP ITR uses can be based
> on the outer destination address (the originating ITR's supplied
> RLOC) or the inner destination address (the originating host's
> supplied EID).
>
> I'm confused here, perhaps in multiple ways. Are there now *two* LISP
> headers on the packet? Is the "outer RLOC the ISP ITR uses" the source
> RLOC or the destination RLOC?
No, just one. When referring to “inner” and “outer”, we mean IP headers.
>
> Negative Mapping Entry: A negative mapping entry, also known as a
> negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
> is advertised or stored with no RLOCs. That is, the Locator-Set
> for the EID-to-RLOC entry is empty or has an encoded Locator count
> of 0.
>
> Is "empty" a distinct representation from "locator count of zero”?
Yes. Added text to make that more clear.
> Section 4
>
> An additional LISP header MAY be prepended to packets by a TE-ITR
> when re-routing of the path for a packet is desired. A potential
> use-case for this would be an ISP router that needs to perform
> Traffic Engineering for packets flowing through its network. In such
> a situation, termed "Recursive Tunneling", an ISP transit acts as an
> additional ITR, and the RLOC it uses for the new prepended header
> would be either a TE-ETR within the ISP (along an intra-ISP traffic
> engineered path) or a TE-ETR within another ISP (an inter-ISP traffic
> engineered path, where an agreement to build such a path exists).
>
> "the RLOC it uses for the new prepnded header", again, this is as the
> destination RLOC (vs. source RLOC)?
Fixed.
> Section 4.1
>
> o Map-Replies are sent on the underlying routing system topology
> using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol.
>
> Just to check my understanding: is the "underlying routing system topology"
> the same as the "underlay”?
Yes.
> Is step (3) just describing more of what step (2) says is "not described in
> this example”?
I lost your reference. Is it to the previous bulleted set or the one starting
with “Client host1 …”?
>
> 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.
>
> Er, what is "this check" that is also performed for initial encapsulation?
> How are there multiple TTL values to compare?
“This check” is outer-header-TTL is < the inner-header-TTL.
> 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) to the inner-header.
>
> nit: the first "inner-header" seems like an editing remnant?
Fixed. This text has changed so many times, it’s not a surprise it became
confusing.
>
> Section 7.1
>
> How is this stateless if it invovles knowledge about the routers between
> the ITR and all possible ETRs (i.e., a set that could change over time)?
The ITR does not keep state about underlay routers between it and the ETR.
> Section 8
>
> This 32-bit vs 24-bit thing is pretty hokey for a standards-track
> specification (yes, I know that LISP-DDT is not standards track at the
> moment).
It is actually useful to allow more instance-IDs but not waste extra bits in
the encapsulation header.
> Section 9
>
> Alternatively, RLOC information MAY be gleaned from received tunneled
>
> What is this an alternative to? The list of four options above?
Doing a mapping system lookup to get an RLOC-set.
> packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache
> entry, one learned from the source RLOC of a received encapsulated
> packet, is only stored and used for a few seconds, pending
> verification. Verification is performed by sending a Map-Request to
> the source EID (the inner-header IP source address) of the received
> encapsulated packet.
>
> The source EID is some random end system, right? So this relys on some
> magic in the ETR to detect that there's a Map-Request and reply directly
> instead of passing it on to the EID that won't know what to do with it?
Not following your description.
> Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and
> might benefit from an explicit section reference to the other document.
Done.
>
> Section 10
>
> What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it
> is not marked as well-known at
> https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is
> probably in order.
It is defined in the xTR definition.
> Section 10.1
>
> Note that "ITR" and "ETR" are relative terms here. Both devices MUST
> be implementing both ITR and ETR functionality for the echo nonce
> mechanism to operate.
>
> Perhaps they could be given actual names so as to disambiguate which steps
> are performed with ITR vs. ETR role?
They are. An ITR is an encapsulator. An ETR is a decapsulator. This is defined
in the definition section. When the functions are co-located, they refer to an
xTR, also in the definition section.
>
> The echo-nonce algorithm is bilateral. That is, if one side sets the
> E-bit and the other side is not enabled for echo-noncing, then the
> echoing of the nonce does not occur and the requesting side may
> erroneously consider the Locator unreachable. An ITR SHOULD only set
> the E-bit in an encapsulated data packet when it knows the ETR is
> enabled for echo-noncing. This is conveyed by the E-bit in the RLOC-
> probe Map-Reply message.
>
> Why is this even optional? If it was mandatory to use, then there would
> not be a question. But at least clarify that the "this" that is conveyed
> is whether the peer supports the echo-nonce algorithm. (Also, subject to
> downgrade.)
Because it has cost implications in a hardware implementation.
> Section 18
>
> o Data-Plane gleaning for creating map-cache entries has been made
> optional. If any ITR implementations depend or assume the remote
> ETR is gleaning should not do so.
>
> nit: this is ungrammatical; "they should not" or "Any ITR implementations
> that depend on or assume that" would fix it.
Fixed. Thanks.
> Section 19.1
>
> Presumably IANA also updated the reference column to point to this
> document?
Yes, from my perspective.
Thanks,
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
