Robin, I haven't seen anyone commenting on your Ivip proposal ('draft-whittle-ivip-arch'). I myself am just now getting around to taking a cursory look, but here are some initial observations. I'm sorry to say that I was only able to get through to the end of Section 5 on this pass. I will try to review more later.
Fred fred.l.temp...@boeing.com --- begin comments --- 1) In your abstract, you say: "Both involve modifying the IP header and require most DFZ routers to be upgraded." Somehow, it seems like a very big assumption to think that most or even some existing DFZ routers could be upgraded to recognize new IP header formats. Indeed, it goes against one of the RFC1955 principles of "no changes to *most* routers". I will check in the rest of the document for what you mean by this, but I am concerned when I see what looks like a non-starter in the abstract. 2) In the Introduction, it seems that a significant amount of the architecture actually appears in other documents. I will check further to see if the base document conveys enough without having to dig up all of the others. 3) 2nd paragraph in Section 2 says: "...each with a common mapping to a single ETR". Why can't the SPI's map to *multiple* ETRs? 4) 4th paragraph of Section 2, it appears that MAB in Ivip means the same thing as VP in IRON-RANGER? 5) 5th paragraph Section 2, it appears that a MABOC is the same as an IRON-RANGER VP provider? 6) 6th paragraph Section 2, "Multihoming end-user networks would typically contract a separate company...". Why would they not instead directly negotiate the mappings with the MABOC themselves? 7) 7th paragraph, Section 2, "...which is typically a subset of all MABs in the Ivip system." IRON-RANGER gateways each advertise the full set of VPs, but I suppose could also be configured to advertise only a partial set as well. Is it not possible for the DITR to advertise the full set, or do you for some reason think it would be best only to advertise a partial set? 8) 8th paragraph, Section 2, with the query service, it looks like Ivip is standing up its own SPI to RLOC mapping service apart from any routing systems or the DNS? Would deploying this service be on the same level of complexity as for the global DNS? 9) 10th paragraph, Section 2, "Each QSR uses a DNS-based mechanism and an additional protocol to discover...". Does this mean that the QSR uses the MAB as an FQDN in a DNS query? That could mean quite a few MABs in the DNS. I think the main difference between this and the IRON-RANGER use of BGP to disseminate VP to RLOC mappings is that BGP can more readily cope with dynamic updates if some RLOCs fail and/or if the VP moves to a different RLOC. Also, each IR has full knowledge of all VPs in its RIB, so there are no per-packet lookups needed. There are probably more differences as well. That said, there may well be a use for keeping the MABs/VPs in *both* the BGP RIB *and* the DNS. The BGP RIB could be used as the full information data base that can be accessed in real time, and DNS could be used as a check to ensure that the MAB/VP is actually "registered" to the ETR thatclaims to own it. 10) 11th paragraph, Section 2, "MABOCs will typically charge their customers for each mapping change." This arrangement seems like it might be very costly to highly mobile SPI prefix holders - why not just a flat-rate? 11) 12th paragraph, Section 2, I am not (yet) seeing an exact mechanism whereby the real-time updated full mapping database is managed. 12) 16th paragraph, Section 2, I think in your description here you are assuming that EIDs are routable within the same scope as RLOCs. That would mean a pure-IPv4 or pure-IPv6 deployment and not an IPv6/IPv4 one? 13) 18th paragraph, Section 2, I will wait until it comes up in later sections, but the notion of modifying the IP heard and changing *most* DFZ routers seems onerous. 14) Section 4, paragraph 1, I have doubts about the ability to deploy what is being called "Modified Header Forwarding". 15) Section 4, paragraph 1, I have strong doubts about the use of the sending host's address as the outer headers source address. First, ICMP messages coming from within the tunnel would not be recognized by the sending host. Second, it only works when both the inner and outer IP protocols are the same version, i.e., it doesn't work for mixed IPv6/IPv4. Also, the BR source address filtering can still be done if the inner source is different than the outer source, because the outer source indicates the previous hop. This is very useful for IPv6-within-IPv4 encapsulation, since the previous hop can be constructed as an IPv6 link-local address that embeds the IPv4 source address. 16) Section 4, paragraph 2, a large part of the motivation for MHF seems to be to avoid PMTUD issues. But, PMTUD issues can IMHO be handled through the use of SEAL with segmentation/reassembly turned off, but with the ability to discover and weed out degenerate links. 17) Section 5.3, paragraph 2, it surprises me to see that aspects of the mapping system are outside the scope of Ivip. Does it mean that there needs to be some adjunct protocols or mechanisms at work in a manner that can plug into Ivip? I guess I don't really understand this business of separation. 18) Section 5.4, paragraph 1, the path MTU determination mechanism seems to require actively looking for a reply to an explicit probe before the MTU can be adjusted. SEAL uses all packets as implicit probes, so there is no need to wait for an explicit probe reply and MTU limitations can be discovered asynchronously. 19) Section 5.4, paragraph 3, "...and ETRs do not communicate at all." - This seems to preclude the ability for the ETR to inform the ITR of any error conditions, e.g., if the ITR thinks that the ETR has the correct mapping when in fact it really doesn't. So, there seems to be a need for the ETR to at least convey error information to the ITR. 20) Section 5.4, final paragraph, the use of vanilla IP-in-IP encapsulation may not interact well with load balancing and/or ECMP in the network. 21) Section 5.5, this section seems to assume no "recursive re-encapsulation", i.e., where there could be a path "ITR(1)->ETR(1)->ITR(2)->ETR(2)-> ... etc." 22) Section 5.7, I am highly skeptical of the MHF approach and/or the use of a non-IP protocol type. I just don't see it reasonable to expect the majority of DFZ routers to update. 23) Section 5.8, I think the goal of unmodified hosts is correct, but should be tempered by "hosts are unaffected by the use of an Ivip-like routing service in the network. I say this, because it is possible that hosts will want to upgrade to support adjunct mechanisms (e.g., HIP, MIP) that are unrelated to the network routing service. 24) Section 5.11, paragraph 3, IRON-RANGER also does do source address filtering at the ETR. That is why each potential ITR needs to securely prove to the ETR that it is authorized to source packets from a particular EID prefix. 25) Section 5.11, paragraph 4, I do not believe the "inner same as outer" source arrangement makes any difference if the source address can be spoofed. This can be fixed by a new mechanism in SEAL whereby the ITR and ETR synchronize sequence numbers so that there is no chance of an off-path spoofing. Note also that the "inner same as outer" approach only works for same inner and outer IP protocol, and only works when both addresses are globally routable. 26) Section 5.12, about full or parital knowledge of MABs, if the number of MABs can be kept manageable (e.g., order of 100k or less) there should be no reason for each DITR to not keep full knowledge. The number of expected MABs may be different for IPv4 (where a significant portion of the address space has already been delegated) than for IPv6 (where a significant portion of the address space has not already been delegated). -- end comments --- _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg