Subject: grow: draft-ietf-grow-anycast-00 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Mar 2005 17:30:53 +0200 (EET)

Hi,

A good document just got better... but there's still a bit of room for
improvement.  I'd suggest the document is revised one more time, and maybe
then it could be ready for WGLC.

substantial
-----------

    Anycast Node: an internally-connected collection of hosts and routers
       which together provide service for an anycast Service Address.
       The entire anycast system for the service consists of two or more
       separate Anycast Nodes.

==> I'm still not 100% sure what you mean by this definition, and whether
the assumptions are correct.  Let me take an example DNS I-root server.  All
the hosts and servers together form one Anycast Node ("I-root"), or..? (The
reason for this, possibly incorrect, assumption is that you use a lot of
plural form above which confuses at least me..)

If this is true, then:
  1) what do you call one instance of the I-root (e.g., one box deployed at
an IX)?  This should be in the references.
  2) the first sentence of section 3.1 seems to be rather confusing.
  3) you seem to have baked in the (good) assumption that there will always
be at least a second backup node (all the other DNS root server letters). 
This is a good thing, but should be more appropriately discussed in a
(sub)section of its own.  For example, including discussion of:
  - why it's a good idea to have multiple backups (e.g., 2-3) for the same
service, so that if something hiccups badly in the anycast, the clients can
fall back.
  - however, sometimes providing this is not possible or reasonable, but as
long as the issue is known, it may be OK
  - the additional "backup" services do not necessarily need to be anycasted.

If this is false, then the definition needs tweaking and 3) above 
needs to be addressed, and you'll need to add the definition of 
something like "Anycast Service" ("I-root") or the like.

    Anycast Node: typically a single node which provides a part of
       Anycast Service.

    Anycast Service: the entire system for making a service available at
       Service Address, consisting of two or more separate Anycast Nodes.

semi-substantial
----------------

4.4.4  Route Dampening

==> one thing that you're not addressing, which might be worth a few 
words is whether it makes sense to damp the anycast services when 
peering with them.  You know, as you're already suggesting automatic 
advertisement/withdrawal scripts/triggers, it might make most sense 
damp the anycast services "at the source", in case a node goes crazy 
and the advertisement goes up and down...

    A dampened path will be suppressed by routers for an interval which
    increases according to the frequency of the observed oscillation; a
    suppressed path will not propagate.  Hence a single router can
    prevent the propagation of a flapping prefix to the rest of an
    autonomous system, affording other routers in the network protection
    from the instability.

==> you're only describing iBGP damping, or eBGP-to-iBGP damping right?  The
text you describe has a hole on [iBGP-]to-eBGP damping?

    Some implementations of flap dampening penalises oscillating
    advertisements based on the observed AS_PATH, and not on the NLRI.
    For this reason, network instability which leads to route flapping
    from a single anycast node ought not to cause advertisements from
    other nodes (which have different AS_PATH attributes) to be dampened.

==> you don't seem to be sufficiently discussing what's the implication of
those _other_ implementations, which in fact damp the NLRI, rendering the
whole anycast service address inoperable?  Maybe it would be useful to also
mention a bit more on this (which behaviour is compliant? which is commonly
deployed? etc.)?

4.8.3  Intra-Node Interior Connectivity

==> You don't sufficiently discuss (IMHO) the constraints of tunneling,
i.e., MTU decrease.  Whether that is a problem or not, whether that affects
the robustness, etc.  Lucky for you, there's
draft-savola-mtufrag-tunneling-02.txt which is heading towards Individual
submission through an AD, which already provides background discussion, but
I think you should refer to that, and add a bit of discussion of this
context here.

6.1  Denial-of-Service Attack Mitigation

    This document describes mechanisms for deploying services on the
    Internet which can be used to mitigate vulnerability to attack.

==> this is mean and lean, but the uneducated will ask, "how again does it
mitigate DoS attacks?".  I think you should add maybe a sentence or two. 
DoS was mentioned only in Goals, very briefly, and that won't be sufficient,
I think...

9.  References

==> the references need to be split to Informative and Normative.  If this
is going for BCP, remember not to put Informational or Experimental RFCs
under normative..

editorial
---------

    When a service is anycast between two or more nodes, the routing
    system effectively makes the node selection decision on behalf of a
    client.  Since it is usually a requirement that a single
    client-server interaction is carried out between a client and the
    same server node for the duration of the transaction, it follows that
    the routing system's node selection decision ought to be stable for
    an order of magnitude longer than the expected transaction time, if
    the service is to be provided reliably.

==> add "at least" before "an order of magnitude" ?

    motiviation for aggregation in many networks' IGPs in any case, since

==> s/motiviation/motivation/

    monitored proactively (Section 5.1) from many points in order to

==> s/Section/see Section/

    The common practice of applying minimm prefix-length filters in

==> s/minimm/minimum/

    For IPv6-numbered services, Anycast Addresses are not scoped
    differently from unicast addresses (see RFC2713 [9]).  As such the
    guidelines presented for IPv4 with respect to address suitability
    follow for IPv6.

    RFC2713 [9] also imposes two restrictions on the use of anycast which
    inhibit deployment of host-based services:

==> you're trying to refer to RFC2373, which in turn was obsoleted by
RFC3513..

7.  Protocol Considerations

    This document does not impose any protocol considerations.

==> I guess this section could be removed...?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/