Re: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer (SEAL)

[Iljitsch van Beijnum <iljitsch at muada.com>]

On 25 feb 2008, at 18:58, Templin, Fred L wrote:

>  "Subnetwork Encapsulation and Adaptation Layer (SEAL)"
>  http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt

"Robust duplicate packet detection": doesn't that go against the end- 
to-end principle? Why is it useful to spend cycles detecting this in  
the adaption layer when the endpoints need to to it anyway?

"virtual ethernet": does this mean that there will be an ethernet  
header in there somewhere? That seems wasteful. Also, I don't see any  
mechanisms for using more than two statically configured tunnel  
endpoints.


The ITE additionally admits all inner packets larger than 2KB into the  
VET interface as single-segment SEAL packets under the assumption that  
original sources that send packets larger than 1500 bytes are using an  
end-to-end MTU determination capability such as specified in [RFC4821].
I disagree with this assumption. Are there ANY RFC 4821  
implementations today?

Is it a good idea to hardcode values? If you run SEAL on a small  
network with a larger MTU you could support larger packets without  
fragmentation. And on MANETs it could be useful to support really  
small MTUs. Or alternatively, it could be good to present an  
artificially larger MTU to the users of SEAL because this saves  
overhead on inner headers.

But the part that really bothers me is that there will ALWAYS be  
fragmentation even when the source host would have been perfectly  
capable of reducing its packet size.

Iljitsch
_______________________________________________
Int-area mailing list
Int-area at ietf.org
http://www.ietf.org/mailman/listinfo/int-area