[rrg] Comments on 'draft-whittle-ivip-arch'

["Templin, Fred L" <[e-mail]>]

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
[e-mail]

--- 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 ---