On Thu, Sep 27, 2018 at 02:06:13PM -0700, Dino Farinacci wrote:
> 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.
Okay. I don't know if "Probe Map-Request" and plain "Map-Request" would
help the reader or not (I did find myself wondering the original question
while reading, of course).
>
> > 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.
Okay, so the ITR is picking an "outer RLOC" based on either the "outer
destination address" or the "inner destination address". My original
reading is that the "outer RLOC" being picked is the same thing as the
"outer destination address", which prompted me to think I was confused. Is
it actually the outer source address that's being selected? It's sounding
like I'm just not sure what field in the outer header the phrase "outer RLOC"
is referring to.
> >
> > 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.
Thanks! (I thought I had found some text elsewhere, maybe not even in this
document, to support my thought that they were the same, so it's good to
know that they're not.)
> > 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.
Okay. I don't request any text change here; I'm sure most readers are more
used to these terms than I am.
> > 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 …”?
The "Client host1" one. Basically, I'm thinking that sending a Map-Request
(step 3) is a method of mapping the destination EID to an RLOC (step 2).
Well, assuming a useful Map-Reply eventually shows up, I suppose.
> >
> > 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.
Ah, I see now that "this check" is both in "Failing to perform this check"
and the start of the following sentence. In the first sentence of the
bullet point, though, it reads like "do X, if condition". The last
sentece is just saying "check condition" without an apparent "do X"
associated with it. So maybe it's better to say something about "when
performing initial encapsulation, the ITR or PITR must ensure that the
outer TTL is less than the inner 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.
Understandable!
> >
> > 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.
Ah, so this is basically a "computed once by the network administrator,
then used as a configuration parameter" thing.
> > 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.
I'd suggest something like "Instead of using the Map-Cache or mapping
system, [...]", as I was very uncertain how "Alternatively" was intended to
be interpreted.
> > 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.
The xTR receives an encapsulated packet (i.e., a data-plane message), and
can use the outer/inner IP headers to get an RLOC/EID pair. The EID of
this pair, in general, is some end system, not necessarily an ITR or
router at all. The xTR is supposed to do verification by sending a
Map-Request to this source EID, some arbitrary end-user system. This
Map-Request is presumably not actually going to get *delivered* to the
system identified by that EID, right? So is it better to say "sending to
the ETR responsible for that EID" or something like that?
> > 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.
Ah, sorry for missing it.
> > 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.
In the narrative, we say things like "[w]hen the ETR next sends a data
packet to the ITR". On the face of it, this phrase is absurd -- by
definition, an ITR is sending a data packet to an ETR, not the other way
around. I know that in this example both are xTRs, but I feel pretty
strongly that it does a disservice to the reader by attempting to use the
role from the initial exchange as an identifier, as opposed to using
a distinct identifier that does not come into conflict with a later role.
> > 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.
It could be useful to document that in the RFC, though I don't feel
particularly strongly about it.
Thanks,
Benjamin
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
