[RRG] LISP-ALT: coordination between ITRs and/or ETRs?

[Robin Whittle <rw@firstpr.com.au>]

Hi Scott,

In your message 1085 in the "Question about ITR and ETR deployment
thread", you wrote:

> The more we take these ideas and try to apply them to real life
> operations, the more we realize how helpful coordination among
> xTRs is.  In order for a site to be able to coordinate behavior of
> its xTRs, to any degree and in any way it chooses, it is good to
> have them under the site's direct control.  I don't believe we can
> predict or should control how a site's xTRs will need to work
> together -- they might do something surprising.  So I don't think
> a site should depend on inter-provider cooperation.  That means I
> believe that it's better to place xTR functionality in CEs.

While I realise you intend many routers to perform both ITR and ETR
functions, these are distinct functions in LISP-ALT and LISP-NERD
and in all the other potentially practical map-encap schemes: APT,
Ivip and TRRP.

What sort of coordination do you envisage in LISP-ALT?

I understand that some (all?) ETRs are authoritative sources of
mapping information, which is different from other proposals - and
functionally different from their basic role (as in all other
proposals) of decapsulating packets and delivering them to the
destination.

I understand from your message you don't want to have any
coordination between ETRs in different provider networks.

I understand that with LISP-ALT, if an end-user network multihomes
via ETR-A via provider network ISP-A and ETR-B via provider network
ISP-B, then these two ETRs need to coordinate their operations in
various ways, including perhaps:

1 - These ETRs need to be able to accept mapping from the end-user
    since they are the (the only possible?) authoritative query
    servers for this end-user's mapping.

    I think this means that the ALT network needs to know about
    these ETRs, be able to reach them, and know that these alone
    are the authoritative servers for mapping queries.  I have no
    understanding of how you would achieve this in practice.

2 - These ETRs need to compare notes about the reachability of each
    other, and potentially of any other ETRs the end-user's network
    uses right now, or could use, and which are mentioned in the
    mapping.  For instance, I think LISP-ALT involves ETRs returning
    reachability bits in some way to ITRs which request mapping.

I thought that ETRs were in ISP networks, and therefore operated by
the ISPs.  This would involve the ISP in some very tricky
authentication stuff to ensure its ETR only cooperated with the
right ETRs in other ISP networks, in respect of mapping,
reachability, etc. of each particular end-user.

However, you wrote that xTRs should be located at the CE point - I
understand this is the Customer Edge router, owned and controlled by
the end-user, connecting to the ISP's Provider Edge router.

That makes coordination between these ETRs a lot easier to organise.

As far as I know, there is no need to coordinate ITR functions with
ETR functions, except to the extent that your system requires ITRs
to determine reachability to ETRs, and to determine each ETR's
ability to reach the destination.  Ivip doesn't require this, except
perhaps as a by-product of PMTUD between the ITR and ETR, which is
only required if the ITR is tunneling packets longer than some length.

Do ITRs need to coordinate with other ITRs?  In Ivip, they don't.

In LISP, as far as I know they don't.

The way LISP-ALT differs from other map-encap proposals in this
respect and in its preferred or required placement of ITR and ETR
functions would be good material for the Taxonomy.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg