Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared

Hi Dino,

If I was confused about some aspects of LISP-CONS then I figure
other people may have been confused too.

When I wrote my comparison, it was my impression that in
LISP-CONS, as in LISP-NERD LISP 1 and LISP 1.5 (though the I-D
says very little about 1.5) that the mapping data contains
potentially multiple RLOC addresses, each with a Weight and
Priority.  This is for the purpose of the ITR making its own
decisions about which of the ETRs (one ETR is hopefully at each
RLOC location) is currently reachable, including by receiving ICMP
messages in response to encapsulated data packets which didn't
make it to an ETR and probably also from messages sent by ETRs
back to the ITR.

So as part of my comparison I wrote (RW1):

>> LISP-NERD/CONS:  As noted above, ITRs have complex functions,
>> including making decisions on a packet-by-packet basis for MH
>> service restoration, TE and I think load balancing functions.
>> The ITR may or may not communicate with the ETR, but I think
>> the ITR is always ready to accept ICMP messages as sign it is
>> tunneling the data packets to the wrong address.

to which you replied (DF1):

> I beg to differ. The ITR simply does a cache lookup on the DA
> when the DA has a routing table miss or a default route match.
> When the cache lookup returns an RLOC it slaps a header on. It's
> as simple as that.

which made me think that you were saying, in effect, that "ITRs
don't have complex functions, they make no decisions about
multihoming service restoration, traffic engineering or load
balancing.  ITRs don't communicate with the ETR and they don't
accept ICMP messages."

So I looked closely at the LISP-CONS I-D, in particular at this
paragraph in 6.4:

  Priority, Weight, Unused, Loc-AFI, Locator:  See [LISP-01] for
  details.  Oh, so it's just like a Blackberry.

and figured the first part of this meant that Priority and Weight
were unused.  This interpretation was compatible with my
understanding of your comment DF1.

So I spent several hours carefully reading:

  http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt
  http://www.dinof.net/~dino/ietf/draft-meyer-cons-01.txt

and revising my comparison:

  http://www.firstpr.com.au/ip/ivip/comp/

with about 2000 words of text in green - in a version now archived at:

  http://www.firstpr.com.au/ip/ivip/comp/    archive-1.html

(Please delete the spaces - I don't want this page found by
 search engines.)

to make it compatible with my new understanding based on your
comments, such as DF1 in:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01730.html

Now I think this was based on my mistaken understanding of DF1,
because now you write (DF2):

> Locator reachability is done outside of the mapping service. So
> once an ITR gets a mapping, from any database mapping service,
> it determines reachability from either ICMP unreachables or the
> loc-reach-bits from returning packets.

and (DF3):

> No, the mapping data tells you want ETRs are configured for an
> EID-prefix, regardless if they are up or down at the time the
> mapping reply is received by any ITR.

The understanding I gain from DF2 and DF3 is that the mapping
information in LISP-CONS is the same or identical to that in LISP
1 and LISP-NERD, in that it includes potentially multiple RLOCs
for each EID, with Weight and Priority for each RLOC, to help the
ITR decide which to use, depending on various things such as how
it does load balancing, what it finds out about reachability

So my paragraph RW1 to which you responded with DF1 seems to have
been correct.

I don't see how your comment DF1, in the context of RW1, is
compatible with your comments DF2 and DF3.

Then:

>> Most importantly, I correct my mistake of not recognising that
>> that LISP-CONS does not contain any Priority or Weight
>> information in its mapping - which means that the LISP-CONS ITR
>> has a simple job, with no decisions or involvement in
>> determining reachability.

> You are mistaken again. ;-) Section 6.4 of the CONS-01 draft
> illustrates that a priority and weight are associated with each
> locator record.

So I looked again at:

  Priority, Weight, Unused, Loc-AFI, Locator:  See [LISP-01] for
  details.

and see that this a list of fields, including the "Unused" field,
to which we are referred to (now) LISP-02, which indicates that
Priority and Weight are used.

I have restored the original text of my comparison.

I would appreciate it if you wrote to the list explaining what
LISP does with multicast packets, because I don't understand
section 9 of the LISP I-D.  As far as I know, there are no packets
to multicast addresses ever being handled by BGP routers, so I
can't see why LISP or any of the other schemes should be concerned
with them, as you suggest they should, in your message:

http://www1.ietf.org/mail-archive/web/ram/current/msg01730.html

> I haven't heard how any of the non-LISP proposals deal with
> ISP-based traffic engineering and multicast.

Also, it would be good if you could give some examples of
ISP-based TE.

  - Robin

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram