Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers

[[e-mail] (Noel Chiappa)]

    > From: Robin Whittle <[e-mail]>

    > AFAIK, you haven't specified the commercial relationship between the
    > operator of the LISP node and the operator of the PETR which it uses.

Right, but obvious commercial arrangements are outside the IETF scope. If
your point was that you can't see that there will be any economically
workable arrangement, that I think would be something that should concern us.
As to that, I have no idea...

    > Do you plan to have provision for two or more PETRs, for redundancy?

You mean, 'would each non-LISP destination site be served by two or more
PETRs'? Or did you mean 'would each LISP source site be served by two or more
PETRs'?

Because I think the original post said something about wanting PETRs
scattered around the system, to minimize extra hops. If a PETR is close to
either the source, or the destination, it will minimize the path length.
Which model you pick probably depends on the economic relationship; i.e.
whether a PETR is associated with a source, or a destination. For the former,
you'd want it close to the source so it can serve multiple destinations
without increased path length, and vice versa for the other relationship.

Anyway, getting back to your original point, the system should _allow_
either, but I'm not sure it should _mandate_ anything.


    > I understand that the concept of a PETR is quite separate from that of
    > the one or more ETRs a LISP node may be using. For LISP nodes which
    > need a PETR, does the LISP node perform its own ETR function?

The terminology may be a little confusing. PETRs serve non-LISP destinations,
i.e. they only handle traffic flowing from a LISP site, to a non-LISP site.
The ETR of a LISP site would, instead, be associated with traffic coming to
the LISP site. How the ETR service for the LISP node is handled is not
something this proposal needs to cover.

    > In the PETR model, I understand the LISP node simply encapsulates
    > packets to send to the PETR

The 'LISP node' might be either i) a LISP site, in which unmodified hosts are
sending packet to an ITR which is doing the LISP encapsulation, or ii) some
other source of LISP-encapsulated packets. Again, the detail there, of where
the LISP-encapsulated packets are coming from, is not something this proposal
needs to cover.


    > The PETR only receives packets from LISP nodes which are addressed to
    > non-LISP addresses.

Right.

    > So there is no need for the PETR to contain or be close to an ITR.

That would likely depend on the economic model/relationship between the PETR,
the non-LISP hosts being served, and the source of the LISP-encapsulated
traffic - see the comment above about PETR placement.


    > Can you list the sorts of scenarios in which the LISP node would be
    > using a PETR?

I'm not sure an exhaustive list is possible. It's just a pretty basic,
generic building block, and those kind of things tend to get used in many
ways that were not forseen. As to a list of possible/plausible ones, Darrel's
original message gave two, perhaps others can come up with more?


    > Must the LISP node be on a global unicast address, or can it be behind
    > one or more layers of NAT?

Again, the term "LISP node" confuses me a little - are you talking of
the original source of the packets, or the ITR, or what?

The ITR will have to have a global unicast address, but that does not prevent
it being behind a NAT - it just has to figure out what the _NAT_'s global
unicast address is, and register that as the RLOC associated with the EIDs
which which that ITR is responsible.


    > Do you expect the LISP node to be connected to the Net via a slow,
    > expensive and unreliable last mile link such as a wireless mobile
    > network? 

I don't think we're making any assumptions about the kind of link it will
have. Like I said, it's a pretty generic building block, and will likely be
used in many different ways.

    > How do you plan to cope with PMTUD and packet loss problems between the
    > LISP node and the PETR?

The same way we would between the ITR and any other ETR, I would assume.


    > How does the LISP node ensure that the PETR is still alive?

That's an interesting point. Some of the techniques used to detect
reachability/liveness of the ETR won't necessarily work with PETRs. E.g.
unless a PETR is co-located in the same box as a PITR, there won't be any
reverse user-data traffic to piggyback nonces on.

However, reachability/liveness testing does fall back to explicit probing,
when none of the other mechanisms are giving a positive signal, so there will
be a backstop. And some of the other ones might work (e.g. PITR/PETR
colocation), there's no way to know about a particular configuration until
it's examined.


	Noel