Subject: [RRG] LISP-NERD reachability and MTU detection

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Dec 2007 17:53:25 +0100

After Eliot's presentation today, I started thinking that LISP-NERD  
could benefit greatly from something like the shim6 REAP reachability  
evaluation mechanism. However, with shim6 we have the limitation that  
we have no bits to play with for datapackets belonging to sessions  
that haven't encountered any failures. Not so with NERD: here we have  
additional bits in every packet. I'm assuming that we can use a few of  
those for reachability and MTU detection. It would work like this:

A LISP-NERD ITR chooses an ETR/locator and assumes it's reachable. It  
sets a "please respond" code point in the NERD header and starts a  
timer. The ETR receving the packet sees the "please respond" message  
and sends back info to the originating ITR that could encompass  
current locator preference information (for traffic engineering), the  
up/down status of other ETRs, the maximum packet size the ETR is  
prepared to receive, possibly (if the ETR supports reassembly) the  
maximum packet size the ETR is prepared to reassemble from fragments.

The ITR receives the message and updates its mapping cache accordingly.

If there is no response before the timer expires, the ITR switches to  
a different ETR.

When mapping state is created and outgoing traffic is flowing, the ITR  
may observe return traffic (if the same ITR and ETR function as ETR  
and ITR, respectively, for traffic in the other direction) and deduce  
that there is adequate reachability. If the ITR doesn't see any return  
traffic, on the other hand, it sets the "please respond" code point in  
the LISP header periodically and awaits replies. Again, if none are  
forthcoming, it switches to another ETR.

Because LISP packets contain a nonce, ITRs can correlate incoming  
responses to their response requests with the original packets, so  
they are in the position to do RFC 4821 path MTU discovery without the  
help from ICMP messages. (They may be limited somewhat because they  
can't decide on the packet size on their own unless we add extra stuff  
here.)

In my book, this is a big win, because it means that the ETRs can be  
completely stateless so it's easy for ISPs to run them for their  
customers and on the ITRs the state required for reachability  
detection is extemely basic: simpler than shim6 and nowhere near  
what's in TCP. It's also soft state that can be discarded and  
recreated without penalty when all ETRs for a prefix (or at least the  
one the ITR will be selecting as the one to use the next time around)  
are up.

If an ITR notices that there is reachability for small packets, it can  
then keep a copy of a large packet that it sends with reply requested,  
and if there is no reply, or if there is an ICMP packet too big, it  
can generate an ICMP too big towards the source of the original  
packet. It doesn't actually know the packet size that can be used on  
the link in the former case, but it could use heuristics or stick to a  
conservative value.

It would of course also be possible to advertise ETR MTU sizes in the  
mapping database (but that doesn't tell us the path MTU).

The question is whether we want to support ITRs and/or ETRs sitting in  
front of / behind 1500 byte MTU links. Having ITRs with this  
limitation is probably doable because as per the above, the ITRs  
SHOULD be able to generate the too big messages back to the source  
hosts and if end-users deploy ITRs in their own networks, they'll  
quickly discover that they'll have to un-break PMTUD. For ISPs we'll  
probably have to mandate the larger packet size because the  
correlation between the deployment of a new box and the start of  
problems won't be as obvious or easy to reverse.

For ETRs, having an incoming MTU of 1500 means that unacceptable PMTUD  
blackholes will happen, or ITRs have to fragment packets and the ETR  
has to reassemble them (for DF=1 or IPv=6). I'm assuming this is  
unacceptable but I'm certainly interested to hear from vendors about  
this.

--
to unsubscribe send a message to [email-masked] 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

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 16 Dec 2007 10:23:45 -0800

> A LISP-NERD ITR chooses an ETR/locator and assumes it's reachable.  
> It sets a "please respond" code point in the NERD header and starts  
> a timer. The ETR receving the packet sees the "please respond"  
> message and sends back info to the originating ITR that could  
> encompass current locator preference information (for traffic  
> engineering), the up/down status of other ETRs, the maximum packet  
> size the ETR is prepared to receive, possibly (if the ETR supports  
> reassembly) the maximum packet size the ETR is prepared to  
> reassemble from fragments.

Iljitsch, you really don't to do this. In a very well behaving  
scenario, this will cause way too much control traffic going to the  
site. Before we put in the loc-reach-bits into LISP this was an  
obvious first thought but was discarded because polling typically  
doesn't scale well when being polled from a million places. Could you  
imagine if everyone polled the DNS root servers *in addition to*  
sending queries for name translations!

Why not just use TTL timeouts and have the ITR, when it needs the  
mapping, send a query or Data Probe and get a new Reply back with  
updated information?

And to be clear, what problem are you trying to solve? Are you trying  
to get EID-to-RLOC record changes to ITRs as soon as possible?

Are you trying to get each ITR a copy of their own mapping with  
different preference and weight information contained in the record?

> If there is no response before the timer expires, the ITR switches  
> to a different ETR.

This is polling for reachability. I don't think you can do much better  
than what we have spec'ed out in the main LISP spec with the loc-reach- 
bits design.

> When mapping state is created and outgoing traffic is flowing, the  
> ITR may observe return traffic (if the same ITR and ETR function as  
> ETR and ITR, respectively, for traffic in the other direction) and  
> deduce that there is adequate reachability. If the ITR doesn't see  
> any return traffic, on the other hand, it sets the "please respond"  
> code point in the LISP header periodically and awaits replies.  
> Again, if none are forthcoming, it switches to another ETR.

That is what the loc-reach-bits do in LISP. Not only does return  
traffic tell you the encapsulator is up, but that encapsulator is  
telling you the reachability status for the other ETRs in the site.

Or are you trying to solve the locator reachability problem when the  
xTRs are placed in PEs?

> they are in the position to do RFC 4821 path MTU discovery without  
> the help from ICMP messages. (They may be limited somewhat because  
> they can't decide on the packet size on their own unless we add  
> extra stuff here.)
>
> recreated without penalty when all ETRs for a prefix (or at least  
> the one the ITR will be selecting as the one to use the next time  
> around) are up.

It might be better if you had xTRs deployed at PEs that they ping each  
other to determine if they are reachable, then they can continue with  
the loc-reach-bits algorithm. That would scale much better but still  
gives me the heebie geebies.  ;-)

Maybe simply a multi-hop BGP session that transmits no routes among  
each other could work, but I still think there is too much  
coordination required of competing ISPs.

> For ETRs, having an incoming MTU of 1500 means that unacceptable  
> PMTUD blackholes will happen, or ITRs have to fragment packets and  
> the ETR has to reassemble them (for DF=1 or IPv=6). I'm assuming  
> this is unacceptable but I'm certainly interested to hear from  
> vendors about this.

It's amazing how people are so fascinated with this MTU issue. So  
what's wrong with fragmentation?

As long as the ITRs fragment before encapsulation, the host and not  
the ETR will reassemble.

Dino

---

From: Tony Li <[email-masked]>
Date: Sun, 16 Dec 2007 11:20:33 -0800

On Dec 16, 2007, at 10:23 AM, Dino Farinacci wrote:

> So what's wrong with fragmentation?

Please see http://tinyurl.com/23nc5x

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 16 Dec 2007 11:35:04 -0800

> Please see http://tinyurl.com/23nc5x

Not that harmful if it's a remote corner case.

Dino

---

From: Tony Li <[email-masked]>
Date: Sun, 16 Dec 2007 15:37:08 -0800

> Not that harmful if it's a remote corner case.

How does it remain a corner case if we make a map-and-encap solution  
the cornerstone of all future Internet routing and we want to  
continue to support bulk transfers?  It would seem that our advice to  
hosts to use 1500 byte MTUs would drive any connection of significant  
bandwidth into being the most common case.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 16 Dec 2007 17:08:44 -0800

> continue to support bulk transfers?  It would

When the end-to-end path is 4470 bytes, than fairly large transfer can  
be done.

> seem that our advice to hosts to use 1500 byte MTUs would drive any  
> connection of significant bandwidth into being the most common case.a

And when it's not 4470 bytes, 1500 bytes would have to be used.

I wasn't able to send quality video about 12 years ago and I can now.  
Technology upgrades allow this to happen. Same for MTU issues.

If this problem really has to be solved, we use translation. So choose  
your poison if you think the alternative is bad.

Dino

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Dec 2007 11:53:33 +0100

Hi Iljitsch,

First, thanks for your comments regarding NERD both now and in the
IST-RING meeting.  Based on those comments and some from others I intend
to update the NERD draft with a bit more theory of operation, as to what
you do with a NERD once you have it.  This also validates Tony's
comments to me that we shouldn't send an unstable experimental draft to
the RFC Editor ;-)  Second, let me remind people what was said in the
RRG meeting.  The general intent of most folks is to first focus on
LISP-ALT.  I would hence encourage you to devote some thought to ALT,
now that you've done so with NERD ;-)

Now please see below.

> those for reachability and MTU detection. It would work like this:

Please note that the LISP architecture at present assumes that we will
survive the tunnel overhead.  We do have the general problem of MTUs
that all tunneling schemes have.  People differ over just how important
this is to solve.  Fred would probably argue "very" while Dino has
argued "not that much".  My own opinion is that over time getting to
1536 isn't that hard.  The bigger problem is getting ABOVE 1536 pre-LISP
(or anything else) encapsulation.   Then you really do need real end to
end MTU discovery, IMHO.

> sets a "please respond" code point in the NERD header and starts a timer. 

s/NERD header/LISP header.  There is only one LISP packet format.  NERD
is merely a way to schmere the data across the globe.

> The ETR receiving the packet sees the "please respond" message and
> sends back info to the originating ITR that could encompass current
> locator preference information (for traffic engineering), the up/down
> status of other ETRs, the maximum packet size the ETR is prepared to
> receive, possibly (if the ETR supports reassembly) the maximum packet
> size the ETR is prepared to reassemble from fragments.

The ETR really only has its interface MTU.  It doesn't look a whole lot
different than any other router.  Again, I think this is a general
tunneling problem, and not something that is specific to LISP.  I do
think the problem is worth considering in LISP's context, but we should
be thinking in more general terms when it comes to solutions (e.g, L2TP,
IPSEC, IP over HTTP, etc., etc.).

Again, thanks for your comments.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Dec 2007 15:35:24 +0100

On 16 dec 2007, at 19:23, Dino Farinacci wrote:

>> message and sends back info to the originating ITR

> doesn't scale well when being polled from a million places. Could  
> you imagine if everyone polled the DNS root servers *in addition to*  

Well, it's one thing or the other: either you make available  
information about the currently reachable locator set for any given  
EID in the mapping system = the mapping system is just as volatile as  
BGP, or you do reachability testing of some kind between ITRs and  
ETRs. I'd say that if you can talk to millions of places, you can also  
respond to reachability probes from millions of places. However, this  
does suggest that something LISP-like isn't the best choice for the  
highest traffic destinations connected to the internet.

> mapping, send a query or Data Probe and get a new Reply back with  

I'm not sure how long you want to make these TTLs, but obviously that  
would be longer than a 10 second or so polling interval which means  
that it's going to take you much longer to detect and recover from  
failures.

> And to be clear, what problem are you trying to solve? Are you  
> trying to get EID-to-RLOC record changes to ITRs as soon as possible?

When I talk to an ETR, I want to know if it's alive fast enough to  
fail over to another one before the transport, app or user stops trying.

> different preference and weight information contained in the record?

If ETRs are sending packets to ITRs anyway it makes sense to add this  
information, yes. Not sure if I'd want to work very hard to make it  
available if it wasn't "free" to do so, though.

> This is polling for reachability. I don't think you can do much  
> better than what we have spec'ed out in the main LISP spec with the  
> loc-reach-bits design.

You assume that each ETR knows whether the other ETRs for that EID are  
reachable. On friday, Eliot said he'd like to see ETR functionality in  
Linksys boxes, so if a user has both cable and DSL connectivity (we  
called this a "basement multihomer" in multi6) the one box would  
handle RLOCs from both so this requirement is easy to meet. However,  
if ISPs run ETRs for the benefit of their customers, this means that a  
single ETR needs to keep track of very many other ETRs in different  
administrative domains and this wouldn't work very well. Also, the  
fact that ETR A can reach ETR B doesn't mean that a given ITR can also  
reach it, especially if ETRs are located at end-user sites where last  
kilometer and POP outages will happen rather than in ISP datacenters  
with multiple connections where uptimes are high.

> what's wrong with fragmentation?

It's basically part of our internet engineering taboos at this stage,  
just like packet reordering. See http://citeseer.ist.psu.edu/335647.html

> As long as the ITRs fragment before encapsulation, the host and not  

You can't fragment IPv6 packets or IPv4 packets with DF=1. So what  
would have to happen is that the LISP tunnel does the fragmenting/ 
reassembly. In this case it would be helpful to know what size packets  
an ETR is willing to reassemble.

I think the reason why Fred is "fascinated" with the MTU issue is  
because he's been trying to solve this for the general tunneling case  
and has found that to be quite hard. For me, I've often been bitten by  
PMTUD black holes, both as a user and as someone who had to make ISP  
infrastructure work without overloading the support lines. In  
addition, I would very much like us to move towards a situation where  
1500 bytes is no longer the de facto IP MTU but people can use  
something larger if their hardware supports it.

We have both the potential to do very quite things (trigger broken  
PMTUD) and very useful things (give people an incentive to deploy  
jumboframes, create the first MTU-robust tunneling mechanism) here so  
we should aim to get things right the first time rather than repeat  
the mistakes made with RFC 1191.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Dec 2007 15:49:14 +0100

On 17 dec 2007, at 2:08, Dino Farinacci wrote:

>> How does it remain a corner case if we make a map-and-encap  
>> solution the cornerstone of all future Internet routing and we want  
>> to continue to support bulk transfers?  It would

> When the end-to-end path is 4470 bytes, than fairly large transfer  
> can be done.

You can do fairly large transfers one bit at a time... That's not the  
issue.

If your ITR has a 4470 byte uplink and your ETR has a 4470 byte  
downlink and there's nothing smaller in the path between them, there  
aren't going to be any problems. In an ISP network it should be  
possible to meet these three conditions if we can get the slower  
brethren and internet exchanges to upgrade. But if we want to deploy  
xTRs in end-user controlled networks, the 1500+ byte MTU requirement  
won't be easy to meet.

> I wasn't able to send quality video about 12 years ago and I can  
> now. Technology upgrades allow this to happen. Same for MTU issues.

Last time I checked, the 10 gigabit ethernet standard had the exact  
same MTU as the original 10 megabit ethernet standard. Now of course  
all our favorite vendors sell non-compliant hardware that can send and  
receive packets larger than that, but unfortunately, hosts and routers  
don't communicate the maximum packet sizes that they can receive to  
other systems on the same subnet, so the only way to packets larger  
than 1500 bytes on ethernet hardware that supports it is by manually  
setting the desired MTU on all systems connected to that subnet. Or  
you can write a draft and try to whip up some IETF support for it:

http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-01.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Dec 2007 11:27:41 -0800

Fragmentation is indeed harmful especially if it is left
unchecked in the presence of sustained high data rates
(RFC4963). Based on analysis over many years, complete
avoidance of all fragmentation and in all operational
scenarios is not possible if applications are to see
a reasonable path MTU. However, fragmentation must be
detected, managed and especially *dampened* in order to
overcome the issues. Having examined this for some time,
my opinion is that effective mitigation of Tunnel Near-
End (TNE) -> Tunnel Far End (TFE) fragmentation and
reassembly begins with protocol and ends with full
deployment of links and TFEs that support larger MTUs.

As many have suggested over the years, IMHO it is better to
have the TNE perform fragmentation on encapsualted packets
rather than leave it up to chance occurrence in the network.
(Iljitsch expressed an idea of having the TNE split 1500 byte
packets up into two 750 byte packets instead of 1480 + 20,
and I admit there is a certain attraction to that concept.)
Unlike Iljitsch, however, I believe there needs to be a
"magic number" above which no TNE->TFE fragmentation is
permitted - call it the "TNE->TFE fragmentation threshold".
Note that this is specifically *not* saying that there needs
to be an upper bound on the tunnel MTU - quite the opposite.

Key considerations are: 1) 1500 bytes has become the
"magic number" expected by applications, 2) 1280 bytes is
the "magic number" specified for IPv6, and 3) fragmentation
at the TFE MUST be kept to a minimum in order to avoid
reassembly misassociations at the TFE. Of these, IMHO 3) is
the dominating consideration followed distantly by 1). ( 2)
is the hard lower bound for IPv6, and we can't change that.)

In particular, I want to see a requirement that TNEs MUST NOT
configure a fragmentation threshold larger than 1500 bytes
for the packets they admit into the tunnel. This would be
large enough to satisfy 1) and 2), yet small enough not to
diminish any integrity checks performed by the TFE during
decapsulation. Even so, in some deployments (i.e., paths that
include links with ~1500 byte or smaller MTUs) a fragmentation
threshold of 1500 bytes will result in fragmentation which MUST
be mitigated and preferrably dampened. Therefore, I believe a
TNE<->TFE protocol such as that specified in sprite-mtu is
required for the near term, but its use can eventually
diminish and fade as network equipment is transitioned over
the longer term.

Specific transitions I would like to see include:

  1) Require that all TFEs configure an EMTU_R that is no
     smaller than 2KB and at least as large as the smallest
     EMTU_R of all underlying links over which the TFE is
     configured. (IMHO 2KB is a good number because it
     allows for a 1500 byte fragmentation threshold at the
     TNE yet allows room for additional encapsulations
     on the path.)

  2) Require that all links transition to adopting IEEE
     802.3as Ethernet Frame Size expansion, or better yet
     Gigabit Ethernet Jumboframes.

  3) Require that all original sources that send packets
     of 1501 bytes or larger with DF=1 also implement
     RFC4821.

This leaves open the question of how does the ITR handle
1501+ byte packets with DF=1. The two viable choices I see
are: a) have the TNE probe the TFE to determine a "Packet
Too Big (PTB) threshold" above which it sends a PTB back to
the original source, or b) simply have the TNE admit the
packet into the tunnel with no PTB returned, and let the
original source deal with any MTU-releated loss. IMHO, TNEs
are advised to do a) until such time that widespread use of
RFC4821 can be confirmed, after which they may do b).

In both the 1500-and-smaller and 1501-and-larger cases,
a simple UDP echo service such as specified in sprite-mtu
would support the short-term requirements until the
wish-list of network equipment transitions is complete.
(Its use would extend also into the long term, but in a
diminshed capacity.)

Fred
[email-masked]                 

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Sunday, December 16, 2007 11:35 AM
> To: Tony Li
> Cc: Iljitsch van Beijnum; Routing Research Group list
> Subject: Re: [RRG] LISP-NERD reachability and MTU detection
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Dec 2007 17:36:33 -0800

Iljitsch,

> the maximum packet size the ETR is  

I assume you are talking here about the ETR's EMTU_R.
RFC1122 couches EMTU_R in terms of the largest packet
the node can *reassemble*, so it will presumably be at
least as large as the largest packet the node can
receive in one piece.

Adding a means for the ITR to discover the ETR's EMTU_R
is something I have proposed in numerous earlier efforts,
and also something I have considered for sprite-mtu. But
AFAICT, we really don't want the ETR to be reassembling
fragmented outer packets any larger than 1500 bytes;
instead, the ITR should send packets larger than 1500
bytes in one piece and/or send back a PTB if they are
too big.

So, IMHO all that needs to be known about the ETR is the
binary as to whether it can reassemble up to 1500 bytes
or not. If we say that all ETR's must be able to
reassemble up to 2KB (enough to cover the 1500 byte
packet plus any additional encapsulation overhead)
then maybe there isn't all that much to be gained by
an explicit EMTU_R discovery exchange?

Fred

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Dec 2007 15:01:39 -0800

>>> It sets a "please respond" code point in the NERD header and  
>>> starts a timer. The ETR receving the packet sees the "please  
>>> respond" message and sends back info to the originating ITR
>
>> you imagine if everyone polled the DNS root servers *in addition  
>> to* sending queries for name translations!
>
> EID in the mapping system = the mapping

Send packets to the destination site with LISP and your syn-ack packet  
returned will give you reachability information.

>> I'm not sure how long you want to make these TTLs, but obviously  
>> that would be longer than a 10 second or so polling interval which  
>> means that it's going to take you much longer to detect and recover  
>> from failures.
>

There will be enough traffic that will hash over to all ETRs at the  
site. And all ITRs at your site will get the reachability information.

> If ETRs are sending packets to ITRs anyway it makes sense to add  
> this information, yes. Not sure if I'd want to work very hard to  
> make it available if it wasn't "free" to do so, though.

But it doesn't change often enough to poll for it. Tell me what you  
think is wrong with the LISP mechanisms?

> You assume that each ETR knows whether the other ETRs for that EID  
> are reachable. On

That is a good thing to assume and a goal to strive for.

> friday, Eliot said he'd like to see ETR functionality in Linksys  
> boxes, so if a user has both cable and DSL connectivity (we called  
> this a "basement multihomer" in multi6) the one box would handle  
> RLOCs from both so this requirement is easy to meet. However, if  
> ISPs run ETRs for the benefit of their customers, this means that a  
> administrative domains and this wouldn't work very well.

You changed configurations all in two sentences. Is the xTR at the  
site or at the ISP, pick one and let's stay coherent with the usage  
case. Or else, I can't follow you.

> It's basically part of our internet engineering taboos at this  
> stage, just like packet reordering. See http://citeseer.ist.psu.edu/335647.html

There is no difference if the host sends smaller packets or a box in  
the network sends smaller packets. I am not advocating that the ETR  
reassemble here. I want to make that clear.

> would have to happen is

Right, you have to obey the protocol spec. So packets will get dropped  
with DF=1. And people turn off ICMP messages as well.

So what's the difference if packets get lost doing a mapping lookup  
(everyone is so sensitive to packet drops there) but for MTU discovery  
purposes it's okay to drop packets?

So the thinking and reasoning is not consistent (not saying yours  
isn't but the general feeling of the list).

> that the LISP tunnel does the fragmenting/reassembly. In this case  
> it would be helpful to know what size packets an ETR is willing to  
> reassemble.

And for IPv6, as long as the ITR's address is the source, it can  
fragment the packet. But in this cast the ETR must reassemble. Too bad  
for IPv6. We'll have to translate for IPv6 then and introduce a new  
set of problems.

> because he's been trying to solve this for the general tunneling  
> case and has found that to be quite hard. For me, I've often been  
> bitten by PMTUD black holes, both as a user and as someone who had  
> to make ISP infrastructure work without overloading the support  
> lines. In addition, I would very much like us to move towards a  
> situation where 1500 bytes is no longer the de facto IP MTU but  
> people can use something larger if their hardware supports it.

Do you think 1500 byte MTU links will still be around say 5 years from  
now? Maybe it's time to clean up some links on the network. I'm sure  
vendors can provide incentive to do this.  ;-)

> jumboframes, create the first MTU-robust tunneling mechanism) here  
> so we should aim to get things right the first time rather than  
> repeat the mistakes made with RFC 1191.

When you think it is right, it will change. It's been a continual  
moving target with multiple moving parts for 20 years. You can never  
be right.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Dec 2007 14:49:24 -0800

>>> solution the cornerstone of all future Internet routing and we  
>>> want to continue to support bulk transfers?  It would
>
> You can do fairly large transfers one bit at a time... That's not  
> the issue.

That is not at all what Tony and I meant.

> aren't going to be any problems. In an ISP

Right.

> network it should be possible to meet these three conditions if we  
> can get the slower brethren and internet exchanges to upgrade. But  
> if we want to deploy xTRs in end-user controlled networks, the 1500+  
> byte MTU requirement won't be easy to meet.a

There is more and more Ethernet being deployed.

Dino

---

From: Tony Li <[email-masked]>
Date: Tue, 18 Dec 2007 00:45:11 -0800

On Dec 17, 2007, at 3:01 PM, Dino Farinacci wrote:

> You can never be right.

No, but you can be complete and self-consistent.

;-)

Tony

---

From: Scott Brim <[email-masked]>
Date: Tue, 18 Dec 2007 17:31:02 -0500

Excerpts from Eliot Lear at 11:53:33 +0100 on Mon 17 Dec 2007:
> > sends back info to the originating ITR that could encompass
> > current locator preference information (for traffic engineering),
> > the up/down status of other ETRs, the maximum packet size the ETR
> > is prepared to receive, possibly (if the ETR supports reassembly)
> > the maximum packet size the ETR is prepared to reassemble from
> > fragments.
> 
> The ETR really only has its interface MTU.  It doesn't look a whole
> lot different than any other router.  Again, I think this is a
> general tunneling problem, and not something that is specific to
> LISP.  I do think the problem is worth considering in LISP's
> context, but we should be thinking in more general terms when it
> comes to solutions (e.g, L2TP, IPSEC, IP over HTTP, etc., etc.).

This is where I come to.  (1) LISP itself cannot and should not keep
track of path MTU; (2) whatever mechanisms we use for path MTU should
work for all packets, whether crossing a LISP encap/decap point or
not.