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
[email protected]
--- 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
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
