Subject: [lisp] #22: rough support for fixing MS requires XTRs to consume packets not address to them

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Sep 2009 12:27:34 -0400

Based on discussion so far, there appears to be a rough consensus in
favor of changing the MS/MR protocol so that XTRs do not need to
consume packets not addressed to them.  I'm going to start a one week
timer on this; any objections should be received by September 18.  If
there are no significant objections we'll declare rough consensus on
the technical direction proposed in the issue at
http://tools.ietf.org/wg/lisp/trac/ticket/22.  Joel provided a bit
more detail on the cross-AFI case.

Obviously we would have a later consensus call on specific text.

I raised the issue.  Dino raised concerns about the cross-AFI case.
My original proposal and Joel's response contained solutions to Dino's
concerns.  Margaret also expressed support.  This is one of the
threads where there isn't really a lot of discussion of things other
than issue #22 with that subject line.

That said, this call is being made more to move the discussion along
than because I have high confidence we're done.  I do think there is
sufficient support to call consensus on a rough technical direction if
no one comments.  However I also suspect this message will result in
comments.  That's fine.  The goal here is to move along discussions
and to make steady progress, not to shut out discussion.

Sam Hartman
LISP co-chair

---

From: Vince Fuller <[email-masked]>
Date: Mon, 21 Sep 2009 21:26:37 -0700

Hi Sam-

Here's how the LISP co-authors want to resolve the open issue around the
origination and processing of Encapsulated Map Requests by ITRs,
Map-Resolvers, Map-Servers, and ETRs. During implementation, we actually
ran this before it was raised on the mailing list and believe we have a
simple but effective way to deal with it.

We plan to incorporate new text in new revisions of the affected drafts
(draft-ietf-lisp-05, draft-ietf-lisp-ms-03, draft-lisp-multicast-02).

	Thanks,
	--Vince
	(for the LISP-main and LISP-MS co-authors)

		--------------------

Problem summary:

  LISP implementors and [email-masked] list members have independently found
  a design and implementation issue with the origination and processing of
  Encapsulated Map-Requests. The LISP team proposes changes to both the base
  LISP specification (currently, draft-ietf-lisp-04.txt) and to LISP-MS
  (draft-ietf-lisp-ms-02.txt) to address this. Since LISP Multicast
  (draft-ietf-lisp-multicast-01.txt) also uses problematic encapsulation
  for certain control traffic, it will also need to be modified.
  
Background:

  The current LISP-MS document (draft-ietf-lisp-ms-02) states that an ITR
  sending a Map-Request to a Map-Resolver sets the destination IP address
  of the message to the EID it is requesting and the destination UDP port
  number to 4342 (LISP-CONTROL). The ITR then adds an additional IP+LISP
  header using the Map-Resolver RLOC as the destination IP address and UDP
  destination port 4341 (LISP-DATA). The message is sent to a configured
  Map-Resolver which decapsulates the Map-Request and forwards it on to the
  ALT. If the destination LISP site is using a Map-Server, the Map-Server
  receives the Map-Request on the ALT then re-encapsulates the message with
  an IP+LISP header using the RLOC of the ETR registered for that EID as the
  destination IP address and UDP destination port 4341 (LISP-DATA).

Why the extra encpaulsation from ITR to MR and from MS to ETR?

  When an ITR is using a Map-Resolver, the ITR is not connected to the ALT
  and therefore has no way to route control messages destined to an EID. For
  this reason, the ITR uses the RLOC of a configured Map-Resolver as the
  destination IP address for Map-Requests; an RLOC, by definition, is
  routable on the non-LISP part of the Internet. To be forwarded on to
  the ALT, though, the target EID is also needed as a destination IP
  address. Adding an extra encpasulation header allows two-stage routing
  to the destination addresses used in those different contexts.

  Similarly, since an ETR using a Map-Server is not connected to the ALT,
  traffic between between Map-Server and ETR must use RLOC-based native
  forwarding. An ETR thus sends its Map-Register messages using its RLOC as
  the IP source address and the Map-Server RLOC as the IP destination.
  Likewise, a Map-Server forwards Map-Requests to an ETR using its RLOC as
  the IP source address and the ETR RLOC as the IP destination; to do this,
  it must encapsulate the original Map-Request since the original destination
  IP address is an EID that is only routable on the ALT.

Problem details:

  As described above, an Encapsulated Map Request currently uses destination
  UDP port 4341 (LISP-DATA). This creates two potential problems:

  1) A packet received by an ETR on port UDP 4341 cannot be immediately
     determined to be control or data. This means that an ETR must perform
     significant processing on such a packet before determining whether it
     needs to either take some control action or forward the packet to a
     destination host. This could make it difficult to implement ETR
     functionality on a router that uses specialized forwarding hardware.

  2) It is currently possible for an encapsulated user UDP datagram received
     by an ETR with outer header UDP port 4341 to be misinterpreted as an
     Encapsulated Map Request. This is because an end system application can
     use UDP port 4342 as a source port for traffic. Return traffic to an
     such an application would be received by an ETR with outer header
     destination port 4341 (LISP-DATA) and inner header destination UDP port
     4342; this could be consumed by an ETR and not forwarded correctly. The
     assignment by the IANA of well-known LISP "service" port numbers will
     prevent this problem in the future but there may be difficulties with
     early trials and deployment prior to such an assignment.

Solution:

  1) Modify the base LISP specification (draft-ietf-lisp-05) to define a new
     LISP control message type called Encapsulated Control Message.

  2) Modify the LISP-MS document (draft-ietf-lisp-ms-03) to specify that
     Encapsulated Map Requests use the new message type and that they are
     sent to UDP port 4342 (LISP-CONTROL) instead of 4341 (LISP-DATA).

  3) Modify the LISP Multicast document (draft-ietf-lisp-multicast-02.txt)
     to similarly replace all use of UDP port 4341 with port 4342 for
     encapsulated unicast PIM Join/Prune messages.

  These changes greatly simplify processing of LISP packets by an ETR: all
  traffic received on UDP port 4341 is decapsulated and forwarded to an end
  system while all traffic received on port 4342 is processed by the ETR
  itself. Furthermore, these changes eliminate any user vs. control message
  ambiguity for traffic received by an ETR on port 4341.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Sep 2009 06:11:26 -0400

Vince, I appreciate that you're working on this issue.

however, Joel and I discussed a solution proposal, and I'm sort of
frustrated/disappointed that you did not respond to that or explain
why your solution should be preferred by the working group.

Here's why I prefer my solution better.  Under your solution, I'm
still required to consume UDP packets not destined to myself.

Consider.  I'm an ETR.  I receive a control packet on port 4342 with
the new encapsulated message type.

Inside that packet is another IP header, another UDP header, and the
actual map request.  That inner IP header is not addressed to me.  So,
I still cannot pass this packet to my local IP and UDP stack.  I have
to implement my own IP option handling, my own UDP checksum handling,
and all the rest of a UDP receiver.

I can do a quick and dirty hack of a UDP receiver rapidly: I've done
so in a couple of hours for another project.  (I'm using another
mechanism for the current LISP; also not appropriate for production
code, but for a variety of reasons it made more sense.) However doing
it right is fairly involved.

In conclusion, I don't think this proposal fully addresses my problem.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Sep 2009 06:42:02 -0400

Let me propose a compromise here.

If the encapsulated control message included the following fields:
* message type 
* Source AFI
* Source IP
* Dest AFI
* Dest EID
* inner message length
* inner message

I'd be totally happy with it.  You may need the source port in there;
I'm not sure.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 09:45:15 -0400

Hi Vince,

>     sent to UDP port 4342 (LISP-CONTROL) instead of 4341 (LISP-DATA).

Are you proposing that we send both unencapsulated LISP control  
messages (such as Map-Register packets) AND encapsulated LISP control  
packets (such as Map-Request and Map-Reply) to the same port (4342)?   
If so, how do you propose to demultiplex the different packet types?   
If I am understanding what you are proposing correctly, it is quite  
problematic.

In LISP -04, the packets that arrive on port 4342 are demux'ed using  
the first 4 bits as a message type, as defined in section 4.1.1.

If encapsulated packets arrive on the same port, what would their  
headers look like?  Do you expect to see IP/UDP (Dest Port = 4342)/ 
LISP Data/IP/UDP(Dest Port = 4342)/LISP Control?  If so, you have a  
serious problem, because there is no easy way to determine whether the  
message is or isn't encapsulated when it arrives at port 4342, either  
the first or second time through the receive portion of the stack.   
There is nothing stopping the first four bits of the LISP Data header  
(flags & reserved) from being equal to the values assigned to  
unencapsulated LISP control messages.

>   3) Modify the Multicast document (draft-ietf-lisp-multicast-02.txt)
>     encapsulated unicast PIM Join/Prune messages. LISP
>

You haven't given any justification for why the End-Node-to-ITR or ETR- 
to-End-Node communication can or should be encapsulated.  Sam and Joel  
proposed that it should not be encapsulated at all, and I prefer that  
solution.  Is there a problem with that solution that caused you to  
consider this alternative?  If so, could you explain what it is?

Thanks,
Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 09:09:37 -0700

> why your solution should be preferred by the working group.

I did respond both publicly and privately with Joel.

Dino

> and all the rest of a UDP receiver.

Use APIs in the LISP process.

And we need to make this simple for the network architecture and users.

> In conclusion, I don't think this proposal fully addresses my problem.

The proposal makes a small change to what we have now. So we can  
process the various options of mixed address families and keeping the  
ALT and other mechanisms pure.

What Joel proposes is a huge change to the mapping system. And if you  
encapsulate at the ITR versus the map-resolver is 6 and one-half dozen  
or the other.

Dino

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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 09:10:22 -0700

That is already in the inner map-request. Why duplicate it? Then you  
have a problem with what fields do you pay attention to if they are  
different.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Sep 2009 12:33:40 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> That is already in the inner map-request. Why duplicate it?
    Dino> Then you have a problem with what fields do you pay
    Dino> attention to if they are different.

O, I'm happier with Margaret's solution.  Anything that gets rid of
the inner IP and UDP header works for me.

I explained in my longer message why the inner IP and UDP header are
problematic.  Margaret has explained why they are unneeded.

Unneeded, problematic things should go away.  

I was simply proposing a compromise that might be easier to implement
than just sending the inner map request as Margaret, Joel and I
originally suggested.  I'm definitely happy with that original
approach as well.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 12:37:20 -0400

Hi Dino,

> And we need to make this simple for the network architecture and  

Could you explain how sending encapsulated Map-Requests is simpler for  
the network architecture and users?

> process the various options of mixed address families and keeping  
> the ALT and other mechanisms pure.

This is not the first time that you've indicated that you believe  
there may be problem with "mixed address families" if we do not use  
encapsulation for the Map-Request, but you have not explained what the  
problem would be.  Joel and I have both indicated that we don't see  
why using an unencapsulated Map-Request would cause problems for  
"mixed AFI families".  If you still think this would cause a problem,  
could you explain it?

> What Joel proposes is a huge change to the mapping system. And if  
> you encapsulate at the ITR versus the map-resolver is 6 and one-half  
> dozen or the other.

I don't see how Joel's proposal is a huge change...  Could you explain  
why you see it that way?  If it is roughly equivalent to do the  
encapsulation in the Map Resolver instead of in the ITR, why do you  
object so strongly to doing it in the Map Resolver?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 09:37:48 -0700

> the inner IP and UDP header works for me.

The inner header is easier for an ALT router to process. We really  
don't want to change that.

We want to keep the map-resolver and map-server simpler as well. So  
just prepending and appending headers is simpler.

I don't understand Margaret's proposal because there was too much  
email back and forth and a lot of misunderstandings.

> problematic.  Margaret has explained why they are unneeded.

Well I think they are needed.

> I was simply proposing a compromise that might be easier to implement

The simplest way IMO is what Vince proposed.

> originally suggested.  I'm definitely happy with that original

So, can you briefly summarize Margaret's proposal.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 09:46:11 -0700

> Could you explain how sending encapsulated Map-Requests is simpler  
> for the network architecture and users?

You want to use off-the-shelf routers for the ALT if you can. You want  
the flexibility to send an IPv6 Map-Request that keeps the original  
header built by the ITR to be "routed" by ALT routers on the ALT  
network even when the path from the ITR to the map-resolver is IPv4- 
only.

You need all the fields that is in the current specs so you can debug  
problems easier.

We have capabilities to do traceroute across ITRs and ETRs and have  
plans to do it across the ALT. The packet formats are set up in a way  
right now where all these features fall out easily.

> encapsulation for the Map-Request, but you have not explained what  
> the problem would be.  Joel and I have both indicated that we don't  
> see why using an unencapsulated Map-Request would cause problems for  
> "mixed AFI families".  If you still think this would cause a  
> problem, could you explain it?

For debugability reasons you want to build an IPv6 Map-Request with an  
IPv6 EID being sought in the payload as well as in the destination  
address of the IPv6 header. You want this to be pure so people can  
debug IPv6 separately from IPv4 in a ships in the night approach. But  
the path from the ITR to the map-resolver could be IPv4-only so you  
need to encapsulate.

Joel suggested sending the Map-Request directly from the ITR to the  
map-resolver and have the map-resolver encapsulate to make the packet  
flow on the ALT. That means if you wanted to send a IPv6 Map-Request  
(it should be termed here seeking an IPv6 EID) it would have to be  
built in an IPv4 packet encoded with a payload with an IPv6 EID). As  
you can see there are all sorts of combinations that can arise from  
this.

Does the user type "debug ip lisp mapping" and get IPv6 information?  
Does the user type "debug ipv6 lisp mapping" and get IPv4 headers to  
print out.

There is a huge usability implication with this.

>> you encapsulate at the ITR versus the map-resolver is 6 and one- 
>> half dozen or the other.
>
> I don't see how Joel's proposal is a huge change...  Could you  
> explain why you see it that way?  If it is roughly equivalent to do  
> the encapsulation in the Map Resolver instead of in the ITR, why do  
> you object so strongly to doing it in the Map Resolver?

See above.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Sep 2009 12:56:05 -0400

To restate:
The proposal under discussion is that the ITR would send requests to the 
MR using an IP packet addressed to the MR containing a UDP header with 
the control port, which contains the Map Query that needs to be resolved.

The MR would encapsulate this in whatever fashion the ALT  wants.
Thus, the ITR mechanism is simple and decoupled from the ALT encapsulation.

The MS would use this same simple format when sending the packet from 
itself to the ETR.  Again, this keeps the ETR decoupled from the ALT 
details.

As far as I can tell, any combination of address families for the ITR / 
MR, the ETR / MS, and the EID being sought will work with this setup. 
Obviously, the ITR and the MR have to share an address family, the ETR 
and the MS have to share an address family, and the ETR has to support 
the address family used as the RLOC of the ITR in the request.  But 
there is no coupling among these three.  And there is no coupling 
between that and the address family for the EID.

As for debugging, that seems to be in the eye of the beholder.  The 
question of how a command gives back the current mapping tables in an 
ITR, or generates a query to see the response, is going to depend upon 
the CLI of the device much more than it will upon this encapsulation 
question.

Yours,
Joel

Dino Farinacci wrote:
> header built by the ITR to be "routed" by ALT routers on the ALT network 
> even when the path from the ITR to the map-resolver is IPv4-only.
> 
> address of the IPv6 header. You want this to be pure so people can debug 
> IPv6 separately from IPv4 in a ships in the night approach. But the path 
> from the ITR to the map-resolver could be IPv4-only so you need to 
> encapsulate.
> 
> flow on the ALT. That means if you wanted to send a IPv6 Map-Request (it 
> should be termed here seeking an IPv6 EID) it would have to be built in 
> an IPv4 packet encoded with a payload with an IPv6 EID). As you can see 
> there are all sorts of combinations that can arise from this.
> 
>>> encapsulate at the ITR versus the map-resolver is 6 and one-half 
>>> dozen or the other.
>>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 13:02:44 -0400

> So, can you briefly summarize Margaret's proposal.

I don't really have a proposal.  I agreed with Joel's proposal (in  
response to Sam's original message) that we should use unencapsulated  
packets for all xTR <=> Map Resolver/Server communication, including  
Map-Requests.  So, we'd just send a Map-Request message in a single  
set of IP/UDP headers from one of the ITR's RLOCs to a configured Map  
Resolver.  If the ITR has more than one RLOC at which it could receive  
a reply (such as an RLOC from a different address family, or RLOCs  
with different reachability properties), it could include that  
information in the "Map Reply Record" of the outgoing request.

This approach has several advantages over the encapsulated packets  
described in LISP -04:  It doesn't require ETRs to process packets  
that are not addressed to them, it allows cleaner separation between  
LISP control and data traffic (since they go to separate ports), it  
has somewhat less (bandwidth and processing overhead), and it provides  
better isolation of the details of the mapping system (in case we  
decide to swap ALT out later).

Vince's proposal has some, but not all, of those advantages.  It does  
provide cleaner separation between LISP control and data traffic (as  
they go to separate ports).  It does not require ETRs to pluck packets  
out of the LISP Data stream (as -04 does), but ETRs still have to deal  
with inner headers that aren't addressed to them.  And, it still has  
the problem that the ITR is building an ALT-specific request and  
encapsulating it to the Map Resolver, which  provides considerably  
less architectural isolation than I would like to see, as it won't  
necessarily be a property of all mapping systems that they will want  
an inner packet that is addressed to the source EID.

I have another related issue with the Map-Request, which is that it  
contains both a source EID address and a source EID prefix.  Is it  
expected that an ITR will keep at least one valid source EID around  
for each prefix, so that it can include it (in the Map Request, and  
perhaps as an inner header destination address if we keep the  
encapsulation) when it wants to refresh the RLOC mapping for an EID  
prefix?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 10:03:36 -0700

> To restate:
> The proposal under discussion is that the ITR would send requests to  
> the MR using an IP packet addressed to the MR containing a UDP  
> header with the control port, which contains the Map Query that  
> needs to be resolved.

Is a Map Query different than a Map-Request?

> Thus, the ITR mechanism is simple and decoupled from the ALT  

Which means the MR would have to parse the Map-Request to pull out the  
EID to build the header. An extra cost we did not have when the ITR  
did this.

> The MS would use this same simple format when sending the packet  
> from itself to the ETR.  Again, this keeps the ETR decoupled from  
> the ALT details.

Right.

> As far as I can tell, any combination of address families for the  
> ITR / MR, the ETR / MS, and the EID being sought will work with this  
> setup. Obviously, the ITR and the MR have to share an address  
> family, the ETR and the MS have to share an address family, and the  
> ETR has to support the address family used as the RLOC of the ITR in  
> the request.  But there is no coupling among these three.  And there  
> is no coupling between that and the address family for the EID.

Right, so this is no different from what we have today but you want  
the encapsulating of the control packet to happen on the MR and MS  
where we want the encapsulating to happen on ITR and ETR.

Today an MR/NS is really simple. It just decaps and encaps and looks  
up packets in a routing table. It really doesn't have to run any LISP  
actually. It can be a product from a vendor that wants to sell  
infrastructure but not do the entire LISP spec.

Your proposal makes the MR/MS do the work that the ITR and ETR are  
already doing.

> question of how a command gives back the current mapping tables in  
> an ITR, or generates a query to see the response, is going to depend  
> upon the CLI of the device much more than it will upon this  
> encapsulation question.

Right.

Dino

>> You want to use off-the-shelf routers for the ALT if you can. You  
>> want the flexibility to send an IPv6 Map-Request that keeps the  
>> original header built by the ITR to be "routed" by ALT routers on  
>> the ALT network even when the path from the ITR to the map-resolver  
>> is IPv4-only.
>> You need all the fields that is in the current specs so you can  
>> debug problems easier.
>> plans to do it across the ALT. The packet formats are set up in a  
>> way right now where all these features fall out easily.
>>> there may be problem with "mixed address families" if we do not  
>>> use encapsulation for the Map-Request, but you have not explained  
>>> what the problem would be.  Joel and I have both indicated that we  
>>> don't see why using an unencapsulated Map-Request would cause  
>>> problems for "mixed AFI families".  If you still think this would  
>>> cause a problem, could you explain it?
>> For debugability reasons you want to build an IPv6 Map-Request with  
>> an IPv6 EID being sought in the payload as well as in the  
>> destination address of the IPv6 header. You want this to be pure so  
>> people can debug IPv6 separately from IPv4 in a ships in the night  
>> approach. But the path from the ITR to the map-resolver could be  
>> IPv4-only so you need to encapsulate.
>> map-resolver and have the map-resolver encapsulate to make the  
>> packet flow on the ALT. That means if you wanted to send a IPv6 Map- 
>> Request (it should be termed here seeking an IPv6 EID) it would  
>> have to be built in an IPv4 packet encoded with a payload with an  
>> IPv6 EID). As you can see there are all sorts of combinations that  
>> can arise from this.
>> Does the user type "debug ip lisp mapping" and get IPv6  
>> information? Does the user type "debug ipv6 lisp mapping" and get  
>> IPv4 headers to print out.
>>> explain why you see it that way?  If it is roughly equivalent to  
>>> do the encapsulation in the Map Resolver instead of in the ITR,  
>>> why do you object so strongly to doing it in the Map Resolver?
>> See above.
>> Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Sep 2009 13:10:56 -0400

Yes, I want the MS and MR to do the work of isolating the ITR/ETR from 
the details of the format used by the ALT.  Yes, that means the MS / MR 
are more than just relay nodes.  So be it.
There are presumably a lot more ITRs and ETRs than there are MS and MR, 
so I would prefer that the MS / MR pay the code complexity cost.  The 
request (yes I used Map-Query when I should have said Map-Request. 
Sorry.) rates are presumably going to be low enough that this is quite 
doable.  Frankly, I had not even realized when I read the original map 
server draft that you intended them to be pure relay agents. I had 
thought that their purpose was isolation and versatility.

Yours,
Joel

Dino Farinacci wrote:
>> the MR using an IP packet addressed to the MR containing a UDP header 
>> with the control port, which contains the Map Query that needs to be 
>> resolved.
> 
> EID to build the header. An extra cost we did not have when the ITR did 
> this.
> 
>> As far as I can tell, any combination of address families for the ITR 
>> / MR, the ETR / MS, and the EID being sought will work with this 
>> setup. Obviously, the ITR and the MR have to share an address family, 
>> the ETR and the MS have to share an address family, and the ETR has to 
>> support the address family used as the RLOC of the ITR in the 
>> request.  But there is no coupling among these three.  And there is no 
>> coupling between that and the address family for the EID.
> 
> Right, so this is no different from what we have today but you want the 
> encapsulating of the control packet to happen on the MR and MS where we 
> want the encapsulating to happen on ITR and ETR.
> 
> Today an MR/NS is really simple. It just decaps and encaps and looks up 
> packets in a routing table. It really doesn't have to run any LISP 
>>> original header built by the ITR to be "routed" by ALT routers on the 
>>> ALT network even when the path from the ITR to the map-resolver is 
>>> IPv4-only.
>>> an IPv6 EID being sought in the payload as well as in the destination 
>>>>> you encapsulate at the ITR versus the map-resolver is 6 and 
>>>>> one-half dozen or the other.
>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 10:19:13 -0700

> response to Sam's original message)

Okay, that is good to know. So there are 2 options then.

> that we should use unencapsulated packets for all xTR <=> Map  
> Resolver/Server communication, including Map-Requests.  So, we'd  
> just send a Map-Request message in a single set of IP/UDP headers  
> from one of the ITR's RLOCs to a configured Map Resolver.  If the  
> ITR has more than one RLOC at which it could receive a reply (such  
> as an RLOC from a different address family, or RLOCs with different  
> reachability properties), it could include that information in the  
> "Map Reply Record" of the outgoing request.

Just note this last part happens today the way the Map-Request is  
encoded.

> LISP

Once the encapsulated packet gets to the LISP process because the  
outer header *is addressed to ETRs*, then it can look at the inner  
destination address to see if the EID is one of it's configured EID- 
prefixes. And if not, and the ETR is attached to the ALT, the ETR  
*may* want to forward it.

There is important functionality here that you don't want to lose.

> control and data traffic (since they go to separate ports), it has  
> somewhat less (bandwidth and processing overhead), and it provides  

The separation is made because of using port 4342. Once that pops the  
packet out of the data plane then you can process it. So having the  
inner header destination address not addressed to the ETR has no  
impact on the data plane.

That is the reason for Vince's fix!

> Vince's proposal has some, but not all, of those advantages.  It  
> does provide cleaner separation between

Let me remind you that Vince's proposal is an easy fix to the  
architecture where the ITR encaps Map-Requests and the ETR decaps Map- 
Requests.

> LISP control and data traffic (as they go to separate ports).  It  
> does not require ETRs to pluck packets out of the LISP Data stream  
> (as -04 does), but ETRs still have to deal with inner headers that  
> aren't addressed to them.  And, it still has the problem that the  
> ITR is building an ALT-specific request and

But not in the data plane. So it doesn't matter.

The ITR is not building an ALT specific request. It allows the  
database mapping topology to not have to do deep packet inspection.  
That is a big advantage.

> an inner packet that is addressed to the source EID.

If you make any component in the mapping system have to parse packets,  
then any changes to Map-Requests will require a fork-lift upgrade to  
the entire mapping system. When the mapping system gets to be large it  
will be a complete non-starter.

We think it's a really good feature to make the mapping system node be  
regular ole IP routers. We can do this when the mapping system is a  
DHT as well.

Do you realize that we can take out BGP from the ALT and make it MPLS  
and not have to change the xTRs and MS/MRs if we wanted to? If we  
wanted the ALT to run another protocol like say OSPF, we could do that  
now.

If we wanted the ALT to be a static configuration of a hierarchy like  
DNS is, we can do this now. And we don't have to change code in the  
MRs and MSs to do this. This is extremely powerful.

> contains both a source EID address and a source EID prefix.

That is there so when you are debugging on an ALT router you know the  
source of the packet.

>  Is it expected that an ITR will keep at least one valid source EID  
> around for each prefix, so that it

No, why would it need to do that?

And what does "keep source EID around" mean?

> can include it (in the Map Request, and perhaps as an inner header  
> destination address if we keep the encapsulation) when it wants to  
> refresh the RLOC mapping for an EID prefix?

Map-Requests are triggered by a map-cache miss from a data packet. So  
the source is known at that time and inserted in the Map-Request.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 10:24:39 -0700

> Yes, I want the MS and MR to do the work of isolating the ITR/ETR  
> from the details of the format used by the ALT.  Yes, that means the  
> MS / MR are more than just relay nodes.  So be it.

Noted.

> There are presumably a lot more ITRs and ETRs than there are MS and  
> MR, so I would prefer that the MS / MR pay the code complexity cost.

The complexity is internal and not to the user. But the user has a  
level of indirection at the site.

The cost is by the programmer at development time. So it is fixed and  
one-time.

And with the Encapsulating Control Message, we could create a  
virtualized LISP on top of LISP so Map-Replies and even Map-Registers  
could be encapsulated. Think about that for a moment. Could come in  
handy as a great feature.

Also, there are large hosting sites that want to be attached to the  
ALT, so the ITR will need to support sending with a destination  
address to an EID.

> The request (yes I used Map-Query when I should have said Map- 
> Request. Sorry.) rates are presumably going to be low enough that  
> this is quite doable.

That is hard to say. It depends how misconfigured things get.  ;-)

> Frankly, I had not even realized when I read the original map server  
> draft that you intended them to be pure relay agents. I had thought  
> that their purpose was isolation and versatility.

Both. As well as anycast nodes.

Dino

>
> Yours,
> Joel
>
> Dino Farinacci wrote:
>>> To restate:
>>> The proposal under discussion is that the ITR would send requests  
>>> to the MR using an IP packet addressed to the MR containing a UDP  
>> Which means the MR would have to parse the Map-Request to pull out  
>> the EID to build the header. An extra cost we did not have when the  
>> ITR did this.
>>> ITR / MR, the ETR / MS, and the EID being sought will work with  
>>> this setup. Obviously, the ITR and the MR have to share an address  
>>> family, the ETR and the MS have to share an address family, and  
>>> the ETR has to support the address family used as the RLOC of the  
>>> ITR in the request.  But there is no coupling among these three.   
>>> And there is no coupling between that and the address family for  
>>> the EID.
>> Today an MR/NS is really simple. It just decaps and encaps and  
>> looks up packets in a routing table. It really doesn't have to run  
>> any LISP actually. It can be a product from a vendor that wants to  
>> sell infrastructure but not do the entire LISP spec.
>>> As for debugging, that seems to be in the eye of the beholder.   
>>> The question of how a command gives back the current mapping  
>>> tables in an ITR, or generates a query to see the response, is  
>>> going to depend upon the CLI of the device much more than it will  
>>> upon this encapsulation question.
>> Right.
>> Dino
>>>
>>> Yours,
>>> Joel
>>>
>>>
>>> Dino Farinacci wrote:
>>>>> Hi Dino,
>>>>>
>>>>> Could you explain how sending encapsulated Map-Requests is  
>>>>> simpler for the network architecture and users?
>>>> the ALT network even when the path from the ITR to the map- 
>>>> resolver is IPv4-only.
>>>> We have capabilities to do traceroute across ITRs and ETRs and  
>>>> have plans to do it across the ALT. The packet formats are set up  
>>>> in a way right now where all these features fall out easily.
>>>>>> The proposal makes a small change to what we have now. So we  
>>>>>> can process the various options of mixed address families and  
>>>>>> keeping the ALT and other mechanisms pure.
>>>>>
>>>>> This is not the first time that you've indicated that you  
>>>>> believe there may be problem with "mixed address families" if we  
>>>>> do not use encapsulation for the Map-Request, but you have not  
>>>>> explained what the problem would be.  Joel and I have both  
>>>>> indicated that we don't see why using an unencapsulated Map- 
>>>>> Request would cause problems for "mixed AFI families".  If you  
>>>>> still think this would cause a problem, could you explain it?
>>>> For debugability reasons you want to build an IPv6 Map-Request  
>>>> with an IPv6 EID being sought in the payload as well as in the  
>>>> destination address of the IPv6 header. You want this to be pure  
>>>> so people can debug IPv6 separately from IPv4 in a ships in the  
>>>> night approach. But the path from the ITR to the map-resolver  
>>>> could be IPv4-only so you need to encapsulate.
>>>> Joel suggested sending the Map-Request directly from the ITR to  
>>>> the map-resolver and have the map-resolver encapsulate to make  
>>>> the packet flow on the ALT. That means if you wanted to send a  
>>>> IPv6 Map-Request (it should be termed here seeking an IPv6 EID)  
>>>> it would have to be built in an IPv4 packet encoded with a  
>>>> payload with an IPv6 EID). As you can see there are all sorts of  
>>>> combinations that can arise from this.
>>>>>> What Joel proposes is a huge change to the mapping system. And  
>>>>>> if you encapsulate at the ITR versus the map-resolver is 6 and

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 13:33:55 -0400

On Sep 22, 2009, at 1:03 PM, Dino Farinacci wrote:
> up packets in a routing table. It really doesn't have to run any  
> LISP actually. It can be a product from a vendor that wants to sell  

Your current perception of the MR and MS as BGP routers is  
understandable, given the nature of the ALT.  However, that isn't  
guaranteed to be a constant for LISP.  The constant will be that the  
MR and MS provide a mapping service to their clients (ITRs and ETRs).   
Ideally, the interface to the mapping service should remain constant,  
even if the underlying mapping system changes.  So, it doesn't make  
architectural sense for an ITR to build an encapsulated ALT mapping  
packet and send it to the MR.

I also don't think it is realistic that the MR/MS will remain as  
simple as you describe, nor do I believe that it is possible (or even  
desirable) for the MR or the MS  to have no LISP-specific code.

ITRs register with Map Servers, so obviously Map Servers will have  
LISP-specific code to process and maintain those registrations.   Map  
Servers also need authentication information configured for each of  
the ITRs they serve, etc.

There are also likely to be a number of anti-spoofing requirements for  
the mapping system that go well beyond the need to read the EID from  
the request.  For example, the mapping system (at one end or the  
other) will have to check the contents of the "Map Reply Record" if  
one is included in the Map Request, to ensure that the mapping  
information in that reply is accurate, and that it is consistent with  
the source RLOC(s) included in the outer header(s).  We may also have  
to do something to authenticate the map replies, which will almost  
certainly involve processing the contents bytes of the reply packet.   
It might, for example, involve verifying the reply, hashing the  
contents of the reply, and signing the reply with a certificate...

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Sep 2009 13:43:43 -0400

I must be misunderstanding your point:

Dino Farinacci wrote:
...
> then any changes to Map-Requests will require a fork-lift upgrade to the 
> entire mapping system. When the mapping system gets to be large it will 
> be a complete non-starter.
...

If MR and MS nodes are pure relay, then in order to change the format of 
a Map Query, as sent by an ITR, every ETR in the world would have to 
have the upgraded software.
In contrast, MS could accept an alternative form, and transform it to 
whatever the ALT handles.  And MRs (which have registrations from ETRs) 
could, at least in theory, transform the ALT format into whatever the 
ETR wants.

In practice, I think that changing the map request or map response 
format is going to be extremely difficult under either model.  But if I 
had to pick one that I thought might be upgradeable, it would be an 
approach with MR and MS as active components rather than merely relays.

Yours,
Joel

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 13:55:14 -0400

On Sep 22, 2009, at 1:19 PM, Dino Farinacci wrote:
>> that are not addressed to them, it allows cleaner separation  
>> between LISP
>

Are you picturing ETRs as multi-interface routers that may serve as  
transit points in the ALT?  I thought that the ALT topology was  
entirely separate from the RLOCs topology, so it seems somewhat broken  
for an ETR to take a packet that was already processed by the ALT (and  
then sent to the ETR at his RLOC), and send it back into the ALT.   
Shouldn't the ITR get a negative response instead?

> The separation is made because of using port 4342. Once that pops  
> the packet out of the data plane then you can process it. So having  
> the inner header destination address not addressed to the ETR has no  

I agree that Vince's proposed change would fix one part of the  
reported problem -- the need to pluck Map-Requests out of the data  
stream.

Are you effectively saying that the inner encapsulation is meaningless  
at this point, except as a 28 to 48 byte field that holds one IP  
address that is already included elsewhere in the packet?  What is the  
ETR supposed to do if there are errors in the inner packet that  
require an ICMP response?  Or if the inner packet is _not_ addressed  
to one of the ETRs RLOCs?  Which RLOC should the ETR use for a reply  
if the inner and outer source RLOCs don't match?

> That is there so when you are debugging on an ALT router you know  
> the source of the packet.
>

> Map-Requests are triggered by a map-cache miss from a data packet.  
> So the source is known at that time and inserted in the Map-Request.

I was told in another thread that it would be possible, and probably  
desirable, to refresh map cache entries before they expire.  So, I  
won't necessarily have an outgoing packet with a destination EID at  
that time.  So, what would I use as the destination EID for the inner  
header, instead?   Do I need to store the original EID that was used  
to create the mapping, so that I can use it again?  Choose an  
arbitrary EID from the prefix?  Something else?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 12:17:09 -0700

>  was told in another thread that it would be possible, and probably  
> that time.  So, what would I use as the destination EID for the  
> inner header, instead?   Do I need to store the original EID that  
> was used to create the mapping, so that I can use it again?  Choose  
> an arbitrary EID from the prefix?  Something else?

The destination-EID in refreshes can use the EID-prefix with zero-fill  
host bits. I will make a note to make this more clear in the spec.

You said source-EID in your last email but I see you meant destination- 
EID. Ack.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 12:27:55 -0700

>> If you make any component in the mapping system have to parse  
>> packets, then any changes to Map-Requests will require a fork-lift  
>> upgrade to the entire mapping system. When the mapping system gets  
>> to be large it will be a complete non-starter.
> ...
>
> If MR and MS nodes are pure relay, then in order to change the  
> format of a Map Query, as sent by an ITR, every ETR in the world  
> would have to have the upgraded software.

You will find that if you change the Map-Request format, all of xTRs  
and MS/MRs will have to change. In our scheme only the xTRs do. The  
reason the MS/MR would change in your proposal is because you are  
requiring them to parse the Map-Request.

> In contrast, MS could accept an alternative form, and transform it  
> to whatever the ALT handles.  And MRs (which have registrations from  
> ETRs) could, at least in theory, transform the ALT format into  
> whatever the ETR wants.

Using the destination address as an EID is not an ALT specific  
requirement.

In an enterprise, ala LISP variant 1.0, Map-Requests will be sent in  
the default VRF. When you don't have a routing table size problem,  
EIDs could be routable in such environments.

I also see that an ALT that runs a DHT will cause a routing table to  
be built where the key is an EID to a standard routing table. A DHT  
can be just like any other routing protocol.

> format is going to be extremely difficult under either model.  But  
> if I had to pick one that I thought might be upgradeable, it would  
> be an approach with MR and MS as active components rather than  
> merely relays.

If you change the Map-Request format, we have 3 options:

o Create a new LISP type.
o Create a new UDP port number.
o Use versioning.

And in all cases, the xTRs will have to change.

Rather than trying to dominate a design to keep changing the protocol,  
maybe we should build version 1 that works first.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 12:35:47 -0700

> understandable, given the nature of the ALT.
> However, that isn't guaranteed to be a constant for LISP.  The  
> constant will be that the MR and MS

Nothing is guaranteed but ALT is *likely* to stick. It should be clear  
once the benefits are understood.

> provide a mapping service to their clients (ITRs and ETRs).   
> Ideally, the interface to the mapping service should remain  
> constant, even if the underlying mapping system changes.  So, it  
> doesn't make architectural sense for an ITR to build an encapsulated  
> ALT mapping packet and send it to the MR.

And it does. The fact that an EID is a destination address does not  
make the xTRs think the database is of a certain type.

> simple as you describe, nor do I believe that it is possible (or  
> even desirable) for the MR or the MS  to have no LISP-specific code.

Well let's not make them complicated on purpose. If we have a real  
need to make them do more, we add it at that time, with compelling  
benefits.

What Joel proposes is just not different enough from a functionality  
point of view. And we will lose features that I have already outlined  
in previous emails today.

> LISP-specific code to process and

No they don't. ETRs register to Map-Servers.

> maintain those registrations.   Map Servers also need authentication  
> information configured for each of the ITRs they serve, etc.

Map-Servers process Map-Registers period. The way they authenticate  
and what features they do depends on the implementation.

> There are also likely to be a number of anti-spoofing requirements  
> for the mapping system that go well beyond the need to read the EID  
> from the request.  For example, the mapping system (at one end or the

Like what?

> information in that reply is accurate, and that it is consistent  
> with the

That is going to take a lot of complicated protocol machinery.

> source RLOC(s) included in the outer header(s).  We may also have to  
> do something to authenticate the map replies, which will almost  
> certainly involve processing the contents bytes of the reply  
> packet.  It

That is going to take a lot of complicated protocol machinery.

> might, for example, involve verifying the reply, hashing the  

That is going to take a lot of complicated protocol machinery.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 15:54:53 -0400

> No they don't. ETRs register to Map-Servers.

You are right, of course.   I am still struggling with some of the  
LISP terminology.  I apologize.
>
>> maintain those registrations.   Map Servers also need  
>> authentication information configured for each of the ITRs they  
>> serve, etc.
>

It is my understanding that Map-Register messages will include  
authentication information that has to be checked by the Map-Server.   
In LISP -04, Map Servers are required to implement IPsec AH and to  
have pre-shared keys with all of the ETRs from whom they accept  
registrations.  I realize that we may change to a different security  
mechanism at some point, but the need for security processing and some  
sort of credentials for each registering ETR (and/or for each  
registered EID prefix) won't go away.
>> source RLOC(s) included in the outer header(s).  We may also have  

Exactly.  So, there will need to be some complicated LISP-specific  
protocol machinery in the mapping system, whether we have the xTRs  
handle encapsulated Map-Requests or not...

The LISP mapping system needs to provide some form of protection  
against spoofed address mapping, in order for LISP to be operationally  
deployable.  I understand that it doesn't do this now, but it needs to  
be added.  If that's inconsistent with your current architectural  
model for the mapping system, then the architectural model has to  
change.  The requirement for a reasonably secure mapping system isn't  
going to go away just because it requires "complicated protocol  
machinery".

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 14:14:28 -0700

> authentication information that has to be checked by the Map- 
> Server.  In LISP -04, Map Servers are required to implement IPsec AH  
> and to have pre-shared keys with all of the ETRs from whom they  
> accept registrations.  I realize that we may change to a different  
> security mechanism at some point, but the need for security  
> processing and some sort of credentials for each registering ETR  
> (and/or for each registered EID prefix) won't go away.

Using AH or using authentication imbedded in the Map-Register doesn't  
change that a Map-Register needs to be parsed.

>>> for the mapping system that go well beyond the need to read the  
>>> EID from the request.  For example, the mapping system (at one end  
>>> or the
>>
>> Like what?
>>
>>> other) will have to check the contents of the "Map Reply Record"  
>>> if one is included in the Map Request, to ensure that the mapping  

My point is that we should question complicated mechanisms to judge if  
the benefits are compelling for the cost.

> against spoofed address mapping, in

I think the mechanisms we already have are pretty good when you  
compare the features with the cost of the mechanism.

> order for LISP to be operationally deployable.  I understand that it  
> doesn't do this now, but it needs to be added.  If that's  
> inconsistent with your current architectural model for the mapping  
> system, then the architectural model has to change.  The requirement  
> for a reasonably secure mapping system isn't going to go away just  
> because it requires "complicated protocol machinery".

It all comes down to the value of variable "reasonable".

Dino

---

From: Vince Fuller <[email-masked]>
Date: Tue, 22 Sep 2009 14:50:05 -0700

> thought that their purpose was isolation and versatility.

Hi Joel-

Thanks for writing this and other notes in this thread. I agree that
your approach would allow a more clean separation between the service
interface used by ETRs/ITRs and the mapping database system that is
currently built using ALT. From a design and architectural abstraction
point of view, I can certainly see the appeal of clearly isolating any
dependencies on the ALT within Map-Servers and Map-Resolvers.

On the other hand, defining a mechanism for an MR to receive a "raw"
Map-Request from an ITR then generate a new Map-Request on to the ALT
and have an MS reverse the process to propagate the Map-Request to an ETR
will require substantially greater changes to the specifications. A few
other disadvantages that also come to mind include: 1) needing to store
additional state in the MRs and MSs, 2) loss of information that is useful
for debugging Map-Request processing, 3) loss of information that is
potentially useful for future end-to-end security associations. I suspect
that my co-authors and others may have additional thoughts to offer.

My goal in proposing the solution that I outlined last night was to make
minor changes to the existing design to solve two clearly-identified
problems, namely, the difficulty in separating data and control messages
and the potential for user data packets to be mis-interpreted as control
messages; both of these were consequences of using UDP port 4341 for
encapsulated control messages.

While I definitely welcome the larger design discussion that you have
opened, I believe it is a bit out of scope for the specific problem that
we are trying to fix with the existing specifications. Can we agree to
fix this problem while we continue discussing the larger issue of improving
the design of the service interface? Remember that the LISP drafts are all
Experimental; the specific problem we are trying to fix has the potential
to delay implementation and experimentation, something I think we all would
like to avoid.

	Thanks,
	--Vince

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Sep 2009 19:04:34 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    >> So, can you briefly summarize Margaret's proposal.

    Margaret> I don't really have a proposal.  I agreed with Joel's
    Margaret> proposal (in response to Sam's original message) that we
    Margaret> should use unencapsulated packets for all xTR <=> Map
    Margaret> Resolver/Server communication, including Map-Requests.
    Margaret> So, we'd just send a Map-Request message in a single set
    Margaret> of IP/UDP headers from one of the ITR's RLOCs to a
    Margaret> configured Map Resolver.  

Joel went on to point out that  all the information you need--the source RLOC, the source EID, the destination EID--is all already in the map request packet.

    Margaret> If the ITR has more than one
    Margaret> RLOC at which it could receive a reply (such as an RLOC
    Margaret> from a different address family, or RLOCs with different
    Margaret> reachability properties), it could include that

This dosen't work and was not part of Joel's proposal.  The problem is
that the reply record includes entries for all the ETRs for the
domain, not for the current ITR.

1) The ITR may not be an ETR

2) There may be additional ETRs.

Currently, neither the current map request nor Joel's proposal supports including multiple source RLOCs.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Sep 2009 19:11:53 -0400

Thanks Vince.
I am not sure I understand what you are asking.

If you are asking "can we start by putting the change you have proposed 
into the current draft?" then my answer is yes.  Your proposal is an 
improvement and we can put it in this draft.

If you are asking "can we approve this document for publication as an 
experimental RFC without resolving the larger design question?" then I 
think the answer is no.  We have to decide before RFC publication what 
design we want.

Given the state of the work, I do not think the size of the change to 
the spec is a particularly important dimension.  The question is what 
the right approach is, not what the livable approach with the smallest 
change to the draft is.  (Sorry, that sentence is probably overstated 
and probably sounds like I am implying ill will on your or Dino's part. 
  I do not see any ill will or attempt to do something wrong.  I just 
disagree about the priorities.)

Yours,
Joel

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Sep 2009 19:21:40 -0400

Speaking as an individual.

    v> While I definitely welcome the larger design discussion that you have
    v> opened, I believe it is a bit out of scope for the specific problem that
    v> we are trying to fix with the existing specifications. 

No, as the one who opened the issue, I'm quite sure that I mentioned
the fact that an ETR is forced to process UDP packets not destined to
itself as one of the problems I cared about.  So, that part of this is
definitely in scope.
It may not be part of what you chose to work on, but it is part of what I asked the editors and WG to consider.

    v> Can we agree to
    v> fix this problem while we continue discussing the larger issue of improving
    v> the design of the service interface

As I stated this does not work for me.  My critical problem is
processing UDP packets not destined to one of my interfaces.  So, no,
I'm not OK with a solution  that doesn't solve that problem.

    v> ? Remember that the LISP drafts are all
    v> Experimental; the specific problem we are trying to fix has the potential
    v> to delay implementation and experimentation, something I think we all would
    v> like to avoid.

I think that receiving packets not destined for myself is a bigger implementation problem for me than  the aspects of this that you did choose to work on.
However I'm very confused about what this is delaying.
I thought you already had an implementation of an MS and MR.
I want to see this issue fixed reasonably soon because it will allow me to avoid certain implementation hacks and produce a better quality implementation.
However, unlike #2, this  issue  is not blocking my testing.  I think I have a work around.

Is there someone else who has come forward and indicated this is
delaying them?

    v> On the other hand, defining a mechanism for an MR to receive a "raw"
    v> Map-Request from an ITR then generate a new Map-Request on to the ALT
    v> and have an MS reverse the process to propagate the Map-Request to an ETR
    v> will require substantially greater changes to the specifications. 

Can you elaborate on this point?  It's not obvious to me why it's
significantly more complicated than saying that the MR changes the
outer header, and the MS does the same.  You'd need to go through both
for the packet generated by the MR and MS and explain what the source
IP, dest IP, source UDP port, and dest UDP port would be.  That
doesn't seem to bad too me.  What am I missing?

    v> A few
    v> other disadvantages that also come to mind include: 1) needing to store
    v> additional state in the MRs and MSs, 

I'm sorry but I don't see what additional state is needed.
Please elaborate.

    v> 2) loss of information that is useful
    v> for debugging Map-Request processing, 
What information is lost?  As far as I can tell, the only information
that is lost is the EID in the inner packet.  However that's
duplicated in the map request itself.  If the source IP in the inner
packet differs from the source IP in the outer packet, that is also
lost, but I don't see that as a big deal--it's a bug.

What am I missing?

    v> 3) loss of information that is
    v> potentially useful for future end-to-end security associations. 
What information that is lost would be useful for end-to-end security
associations?

In the future, please answer these sorts of questions when you bring
up arguments about increased debugging complexity, increased spec
complexity,or security problems.  If you're going to say that
something makes these worse, give an example.  I realize this was not
your intent, but if you don't answer that question it comes across as
if you are just trying to spread FUD.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 16:41:27 -0700

> Given the state of the work, I do not think the size of the change  
> to the spec is a particularly important dimension. The question is  
> what the right approach is, not what the livable approach with the  
> smallest change to the draft is. (Sorry, that sentence is probably  
> overstated and probably sounds like I am implying ill will on your  
> or Dino's part. I do not see any ill will or attempt to do something  
> wrong.  I just disagree about the priorities.)

What's your opinion about changing implementations? Encap/decap on the  
MR and MS is a huge implementation change and at this point. We don't  
know what will break. There are a lot of features that won't work on  
the test network. Unless, we get a very detailed design, we can't  
evaluate the new proposal.

You would have to detail out:

o How you won't break LISP variant 1.0.
o How you won't break mix-AF support.
o How you won't break lig.
o How you won't break traceroute on the ALT network.
o How you don't break ALT attached xTRs.
o How IPv4 Map-Replies can be returned for IPv6 Map-Requests.
o How map-resolver and map-server caching will be dealt with.
o ICMP unreachables now can be delivered to the requesting ITR. Now  
they will be delivered to
   the encapsulating MR. The MR will have to cache Map-Requests.

We have 3 implementations going now and maybe more coming soon. And  
those 3 implementations don't interoperate now and we need them to so  
we can learn about what's already in the specs. That is, we don't have  
enough data indicating what we have is bad. But we do have data on  
what features we have working.

I would prefer that we use your brain cycles on more critical issues  
like updating map-caches on ITRs when ETRs change their mappings. As  
well as thinking about LISP network component placement for scalability.

IMHO,
Dino

---

From: Vince Fuller <[email-masked]>
Date: Tue, 22 Sep 2009 17:16:40 -0700

> asked the editors and WG to consider.

No, your issue with "an ETR is forced to process UDP packets not destined
to itself" is outside the scope of the specific problem in #22 and the
specific changes that we have proposed.

> I'm not OK with a solution  that doesn't solve that problem.

This sounds like an implementation problem not a design problem.

LISP+ALT has, from the beginning, specified a mechanism that requires ETRs
to accept and process Map-Requests that are destined to their owning EID
prefixes but not to a specific IP address configured on a local interface.
If you consider that behavior to be a problem then it should be tracked as
a separate issue.

> I think that receiving packets not destined for myself is a bigger
> implementation problem for me than  the aspects of this that you did
> choose to work on.

Others have successfully implemented this behavior which suggests that it
is not a fundamental problem.

In any case, it is unrelated to the issue of UDP port 4341 being used for
both control and data packets and should be addressed separately.

> I want to see this issue fixed reasonably soon because it will allow me to
> avoid certain implementation hacks and produce a better quality
> implementation.

We do have implementations of MS, MR, and the required Encapsulated Map
Request processing on ITRs and ETRs. We have discovered through testing those
imlementations that Map-Request processing efficiency will be poor and that
deployment on an operational network will be problematic as long as UDP port
4341 is used for both user data packets and Encapsulated Map Requests. The
changes that I described in my earlier message are intended to fix that
specific problem not to change the design of MS/MR functionality.

	--Vince

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Sep 2009 21:05:11 -0400

>> wrong.  I just disagree about the priorities.)

    Dino> You would have to detail out:

OK.
So, first let me detail changes to  the map request.
We add a second source RLOC field  so that an ITR can include two source RLOCs from different address families.
It's my understanding that today in the cross-AFI case,  I'll include one RLOC in the IP header and may include an RLOC of the opposite address family in the source RLOC field of the map request.

We need to include   two RLOCs in the map request.

An alternate design would be to have the MR and MS swap the RLOCs if
they swap address families of the outer header.  I prefer to include
two RLOCs in a map request because the behavior of the MR and MS is
simpler.

Encapsulation behavior: I have a map request.  I'm an MS or an ITR and
I want to produce a packet suitable for sending over the RLOC
internet.
I have a destination RLOC I wish to send to.

I search the map request packet.  If there is no source RLOC in the
map request packet of  the destination RLOC AFI,  I will use one of my RLOCs.
I construct an IP header using the source RLOC I just selected as the
IP address, the destination RLOC that is an input to the encapsulation
procedure as the destination.  Inside this is a UDP header.  I select
a valid ephemeral port as the source port and the destination port of
4342.

An encapsulator MAY choose to always use their own source RLOC .  The
reason for allowing this is to support map servers that have URPF that
prevent them from using the ITR's RLOC.  That probably decreases
debugging success, but may be better than completely failing to work
as an MS.

Decapsulation procedure: I'm an MR.  I've received the result of the
encapsulation procedure.  I wish to produce a packet for sending over
the alt.  I search the map request for an RLOC of the same AFI as the
destination EID.  If there is no such RLOC, I pick one of my own
RLOCs.  Picking my own RLOC is an arbitrary decision; there may be
other decisions.  As I mention in issue #23, this is already undefined
in the current system.  I needed to propose a specific fix to #23 in
order to answer your questions below.

I construct an IP packet of the version of the destination EID.  The
source address is the RLOC I've picked above--either the RLOC from the
map request or the RLOC of the MR if no such RLOC exists.  The
destination IP address is the destination EID.  The source UDP port
can be the same as from the packet I received, if that helps
debugging.

ETR behavior: The ETR receives the map request.  It generates a reply
and sends it to UDP port 4342 on one of the source RLOCs read from the
packet.  This fails if the ETR and ITR do not share RLOCs in the same
address family; so does the current procedure.

    Dino> o How you won't break LISP variant 1.0.

I think LISP 1.0 is out of scope for this WG.  If a particular
 implementation wants to support it,
that's there business.  However I don't think spending time on LISP
1.0 is something this WG should do.

    Dino> o How you won't break mix-AF support.

The encapsulation procedure above always succeed.

The map request packet itself is never modified by the encapsulation
or decapsulation procedure.
So, the ETR will receive the map request.
If the ETR and ITR share a source RLOC AFI in common, then the ETR can respond.
That's sufficient to argue that cross-AFI is not broken.

    Dino> o How you won't break lig.

LIG generates a map request with either one or two source RLOC entries
depending on what address families it supports.  It follows the
encapsulation procedure with the destination RLOC set to the RLOC of a
map resolver.

    Dino> o How you won't break traceroute on the ALT network.

The alt draft does not specify traceroute.  If you would like to make
a proposal that we support traceroute on the alt and give requirements
for that, we can consider that as a WG.  Until then, the WG has no
obligation to break traceroute.  However I'm reasonably sure that this
will work or can be made to work with traceroute.

    Dino> o How you don't break ALT attached xTRs.
    Dino> o How IPv4 Map-Replies can be returned for IPv6 Map-Requests.
    Dino> o How map-resolver and map-server caching will be dealt with.
    Dino> o ICMP unreachables now can be delivered to the requesting ITR. Now
    Dino> they will be delivered to
    Dino>   the encapsulating MR. The MR will have to cache Map-Requests.

This is not true in my proposal.  By caching things, an MR could
deliver errors in more cases than it does otherwise, but I think
without caching error handling is good..

    Dino> We have 3 implementations going now and maybe more coming soon. And
    Dino> those 3 implementations don't interoperate now and we need them to so
    Dino> we can learn about what's already in the specs. 

The most important thing you can do to improve interoperability to use
standard components consistent with their specs.

we found problems with lig because LISP implementations had to use
their own UDP stack because of this issue.  Implementing LISP is
harder because of this issue.

We found problems with LISP implementations because LISP does not use
IPsec as specified but instead diverges from the IPsec standards.

I expect that every time we run into things where LISP just uses a
header or packet type of some other protocol but does not use the
semantics and does not allow integration with a normal implementation
of that protocol, we'll find huge interoperability problems.

I may not have as much experience implementing protocols as some
people here, but I can say with very high confidence that improving
use of existing protocols will significantly help your
interoperability problem.

--Sam with implementor hat on

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 21:12:29 -0400

Hi Vince,

> specific changes that we have proposed.

Have you read issue #22?  It seems to me that it quite clearly  
includes "an ETR being required to process UDP packets not destined to  
itself".  The text of the issue is here:

http://trac.tools.ietf.org/wg/lisp/trac/ticket/22

In fact the sentence above that you claim is outside of this issue is  
almost exactly the same as the first sentence of the issue, itself...

I agree that the changes that you have proposed do not fully address  
this issue.

> is not a fundamental problem.

Not necessarily.  As far as I know, no one who claims to have  
successfuly implemented this has answered questions about how errors  
in these packets are detected and handled.

> both control and data packets and should be addressed separately.

I agree that these issue could be considered separately.  So, perhaps  
you should open a new issue for this one, perhaps referencing issue  
#22 and making it clear how they differ?
> specific problem not to change the design of MS/MR functionality.

I understand, and agree, that you have addressed that particular  
problem.  As I indicated in an earlier message, however, the proposed  
change in the Map-Request encapsulation resolves other issues and has  
other advantages.  Personally, I still support moving to Joel's  
proposal for unencapsulated Map-Requests.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 21:14:09 -0700

Two points:

(1) There are many ways to skin a cat. Just because you prefer  
something doesn't mean it's the right choice. Rather than saying  
something can be done another way, indicate why it is better.

(2) Changing protocols does not mean you are going to improve  
interoperability.

Let's build the right solution for the customers and then make sure we  
spec it out clearly so we have interoperability.

Doing interoperability for sake of sole interoperability does nothing  
for the user if we don't solve the problems the users want us to solve.

Dino

On Sep 22, 2009, at 6:05 PM, Sam Hartman wrote:

> We add a second source RLOC field  so that an ITR can include two  
> source RLOCs from different address families.
> It's my understanding that today in the cross-AFI case,  I'll  
> include one RLOC in the IP header and may include an RLOC of the  
> opposite address family in the source RLOC field of the map request.
>