Early Review of draft-ietf-dots-multihoming-09
review-ietf-dots-multihoming-09-opsdir-early-jaeggli-2021-12-23-00

I have reviewed draft-ietf-dots-multihoming-09 for on behalf of the operations
and and management area directorate. While I think this document is largely
complete, I have a couple of questions ab out the ways in which is proposes to
implment the various cases which may or may not add clarity to the document.

It would seem that the chief difference between the residential CPE case and
the enterprise case would seem to be the intercession of BGP,  Who manages the
CPE from the vantage point of configuration,

In practice I don't see a meaningful difference between a single CPE and
multiple CPEs in the enterprise case (5.2/5.3), source address selection is a
coordination problem in either case? but in fact that's mostly a coordination
problem.  selecting the path to the dots server(s) can be achieved via route
selection if no mechanism for signaling routes between CPEs that seems like a
serious limitation.

In a multihoming scenario involving a provider assigned prefix the prefix may
well be both deaggrated for a large provider assignment and advertised to both
providers (e.g. I have an office which receives a /24 assignment from lumen and
also advertises that self same prefix to zayo), in this case the prefix must be
advertised de-aggregated to both providers. enterprise pa assignments of this
form are necessarily equivalent to pi prefixes from a usage standpoint. which
ip is used for dots signaling in cases like this is necessarily a problem of
coordination whether it be the cpe/router peer interface, router loopback, or
some other source ip enclosed within the assigned prefix (or indeed some other
prefix).

> When PI addresses/prefixes are used, DOTS clients MUST contact all the DOTS
gateways to send a DOTS message.

When engaged in DOS related signaling not all dos attacks are in fact
distributed, when attack traffic is unspoffed as it is in most upper layer
targeting attacks it must necessarily follow a consistent path per attacker, 
moreover, your telemetry may well tell you which ingress interface and
therefore provider needs to receive which signaling sending them to un-impacted
providers unnecessary and may result in unintentional information leakage.

>   The use of anycast addresses is NOT RECOMMENDED to reach DOTS gateways.

provider specific anycasts do not in principle seem worse then  provider
specific unicasts, they allow a provider reduce the ammount of coordination
required within their own infrastructure. assigning a well know anycast for
this purpose among all providers on the other hand sounds like a terrible idea,
for the reasons that well known-anycasts are generally bad.