Subject: [lisp] A proposal for cross-AFI resolution

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Mar 2010 17:55:41 -0400

Hi.  At the meeting I stated a concern about the cross-AFI solution
presented by Dino because I thought it was tied to the architectural
question of whether the map-request should be encapsulated.

I think there is a minor change to Dino's proposal that will resolve my
concern.  As I understand it, Dino proposes to add a source locator
count and a set of AFI/locator pairs to the map request.
With the following two additions  I think I'b be entirely happy doing
that now:

1) If the ETR replies to a map request, it chooses one of these source
locators and does not send the reply to the source address of the
encapsulated packet.  I suspect this may already be part of the
proposal.

2) ETRs MUST handle either encapsulated or un-encapsulated map requests.

I think 2 is very easy to implement now that we don't need the source
address from the map request to generate the reply.

Does this work for folks?

--Sam

---

From: Darrel Lewis <[email-masked]>
Date: Tue, 23 Mar 2010 15:02:18 -0700

> Does this work for folks?

ETRs already handle both today (remember that probe packets are map-requests), so I'm not sure why this additional requirement language is needed.

-Darrel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2010 15:00:41 -0700

> encapsulated packet.  I suspect this may already be part of the

It is.

> 2) ETRs MUST handle either encapsulated or un-encapsulated map  

This is already supported in the draft and several implementations.

> Does this work for folks?

Yes, because nothing additional needs to be added.

Dino

>
> --Sam
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Mar 2010 23:27:44 -0400

>>>>> "Darrel" == Darrel Lewis <[email-masked]> writes:

    Darrel>     2) ETRs MUST handle either encapsulated or
    Darrel> un-encapsulated map requests.

    Darrel>     I think 2 is very easy to implement now that we don't
    Darrel> need the source address from the map request to generate the
    Darrel> reply.

    Darrel>     Does this work for folks?

    Darrel>     --Sam

    Darrel> ETRs already handle both today (remember that probe packets
    Darrel> are map-requests), so I'm not sure why this additional
    Darrel> requirement language is needed.

I think today it would be legal to throw away a non-probe map request
that was not encapsulated.  I want to forbid that.

---

From: John Zwiebel <[email-masked]>
Date: Tue, 23 Mar 2010 19:00:58 -1000

> that was not encapsulated.  I want to forbid that.

Why?

Where does it say they would be thrown away?
What about an SMR, would that be thrown away?
We're talking about just one bit here for the probe and one for the SMR.

But in the end, if I don't want to talk to you, why should you have the
authority to tell me that I have to?