Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]

From: [email-masked] (Noel Chiappa)
Date: Fri, 23 Apr 2010 15:32:13 -0400 (EDT)

> From: John Scudder <[email-masked]>

    >> to be clear here, "up" means the box is up and necessarily reachable
    >> from everywhere.

    > Did you mean "*not* necessarily"?

Perhaps - and that's why we differentiate between 'up' (which is
node-specific) and 'reachable' (which applies to a {source, destination}
pair), and why there are mechanisms specifically to test reachability.

Instances have actually been seen in which an ITR/ETR pair were up, and the
routing tables _claimed_ one should be able to get packets from the ITR to
the ETR, but in which various access-control/etc settings prevented packets
from flowing.

    > the concept of 'site' isn't clearly defined in the spec, so I would
    > prefer to discuss this in terms of EIDs instead of 'sites'. 

I get a little antsy using 'EIDs' like that, because an EID is just a _name_,
and one doesn't talk to a name, one talks to the thing the EID names.

But I agree 'site' could be more clearly defined, as 'the collection of end
hosts and associated communication infrastructure named by the EID ranges
advertised by an ETR', or something like that.

    > the LSB is carried in return data traffic... which will not exist if
    > there is no connectivity to any EID prefix, or in various other cases.

The whole up/reachable status thing (above) consists of a number of somewhat
overlapping mechanisms, which did not all arrive at the same time. LSB's are
the oldest one, and one I am not particularly wild about, but anyway...
There's this concept that while none by themselves are 'perfect', and that a
'perfect' mechanism (along speed and robustness axes) would be too expensive,
the collection of them 'tile' the problem-space 'well enough'.

The thing about a lot of the mechanisms that are piggybacked on user traffic
is that there is tradeoff one has to live with in any overlay system such as
LISP, which is that the fan-out at any individual node can be really large
(since you can have neighbours anywhere on the network, not just locally),
and if one uses explicit control traffic for such functions, overhead can
really add up. Piggybacking reduces the overhead, but then you get the 'what
if there is no user traffic' thing. With luck, the control is going the same
direction as the user traffic (e.g. in mapping versioning), and then if
there's no user traffic, it doesn't matter. LSB, alas, goes in the other
direction, so if there's unidirectional traffic it can be an issue, but at
that point other mechanisms in the 'up/reachable' group can backstop.

    > at a minimum the spec ought to point out that this limitation exists a
    > and that solutions are considered out-of-scope. Something like this:

'currently out of scope'... This is the Experimental protocol, not the
Proposed Standard... :-)

    > "This architecture does not provide a solution for data to be reliably
    > delivered to hosts within the site in this scenario; provision of such
    > a solution is beyond the scope of this document."

Make it "not currently provide" and I at least would be OK with that.

	Noel

---

From: John Scudder <[email-masked]>
Date: Fri, 23 Apr 2010 12:51:16 -0700

> the ETR, but in which various access-control/etc settings prevented packets

Sure, hence the question.

> advertised by an ETR', or something like that.

I'll use whatever term you like as long as it's clearly defined.

> that point other mechanisms in the 'up/reachable' group can backstop.

Unidirectional traffic as such is one problem.  Another is noncongruent forward/return paths, which make traffic appear unidirectional even though it's not from the host-host perspective.  Another is the class of problems identified earlier in the thread, where you don't have a complete path in the forward direction, and hence don't ever get enough of a transaction to produce return traffic.  (Yes these all are "unidirectional traffic" when viewed through the right lens.)

> Make it "not currently provide" and I at least would be OK with that.

If you like it better that way it's OK:

"This architecture does not currently provide a solution for data to be reliably delivered to hosts within the site in this scenario; provision of such a solution is beyond the scope of this document."

--John