Hi Iljitsch, >-----Original Message----- >From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] >Sent: Monday, February 25, 2008 2:59 PM >To: Templin, Fred L >Cc: Internet Area >Subject: Re: [Int-area] FW: [RRG] Subnetwork Encapsulation and >Adaptation Layer (SEAL) > >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?
Perhaps the text is a bit misleading. All that was meant by way of implication was that each SEAL packet carries a 32bit Identification that (along with the IP source and destination) can be used by the network to differentiate it from other SEAL packets. This comes into play most prominently for multicast when the network is doing something like the MANET Simplified Multicast Forwarding (SMF), but could be useful for duplicate packet detection for unicast as well. Note that this does not require any particular behavior on the part of the network; it only means that uniquifying information is available should the network need it. >"virtual ethernet": does this mean that there will be an ethernet >header in there somewhere? That seems wasteful. No; no ethernet header. Virtual Ethernet only in the sense that all ingress/egress tunnel routers attached to the same subnetwork see each other as single hop neighbors at the IP layer even though there may be many sub-IP layer hops in-between. >Also, I don't see any >mechanisms for using more than two statically configured tunnel >endpoints. The same abstraction applies for both point-to-point and point-to-multipoint, but the manner in which tunnel endpoints associate with one another are specified in other documents (e.g., tunnel-mode-IPsec-over-SEAL, ISATAP-over-SEAL, LISP-over-SEAL, configured-tunnel-over-SEAL, etc.). >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? I see a standards-track specification, and I see code being submitted to a major OS. Also, AFAICT only one endpoint needs to implement the mechanisms independent of the other endpoint, so there is natural incremental deployment. >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. 2KB- packets are conveyed across the subnetwork even if some cutting and pasting is necessary, and 2KB+ packets are sent into the subnetwork in one piece and either make it through unfragmented or not. So, SEAL "takes care of the smalls, and lets the bigs take care of themselves". > And on MANETs it could be useful to support really >small MTUs. Yes, and thereby avoid the jitter caused by trying to convey larges packet across underprivileged links using a link-specific adaptation. > Or alternatively, it could be good to present an >artificially larger MTU to the users of SEAL because this saves >overhead on inner headers. This is true, too. >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. No fragmentation if the links within the subnetwork configure reasonably large MTUs. Or, if there are bandwidth-constrained links that configure tiny MTUs, better to let SEAL handle it rather than tell the original source that the path MTU is tiny since the tunnel could be rerouted onto a path with a larger MTU at any time. Thanks - Fred [EMAIL PROTECTED] > >Iljitsch > _______________________________________________ Int-area mailing list [email protected] http://www.ietf.org/mailman/listinfo/int-area
