Re: [Dots] Call for adoption on draft-boucadair-dots-multihoming

["Panwei (William)" <[e-mail]>]

Hi,



I support adoption of this draft. And meanwhile, I have some comments.



Nits or Typo:

1.      In section 1, s/To that aim, this document adopts the following methodology/To those aims, this document adopts the following methodologies/.

2.      It's better to use "DOTS signal channel sessions" instead of "DOTS signaling sessions" in Section 1, Section 5.1 and Section 5.3.

3.      In section 4.1, s/Each of these provisioning domains assign IP addresses/prefixes to the CPE/Each of these provisioning domains assigns IP addresses/prefixes to the CPE/.

4.      In section 4.2, the descriptions of the two sub-cases begin as the following way:

1. Provider Independent (PI) addresses: XXXXXXXX

2. PA addresses/prefixes: XXXXXXXX

It's better to change the beginning of the two sub-cases like this:

1. Provider Independent (PI) addresses/prefixes: XXXXXXXX

2. Provider Aggregatable (PA) addresses/prefixes: XXXXXXXX

5.      In section 5.2, the case of figure 6, s/When PA addresses/prefixes are in used/When PA addresses/prefixes are in use/.



Some comments:

1.      I suggest having a detailed explanation of the meaning of Provider-Independent (PI) and Provider-Aggregatable (PA) in Section 3 Terminology. (In addition, I think "Provider-Aggregate" is more suitable than "Provider-Aggregatable".)

The reason I want an explanation of these two terms, is that when I read the draft I got confused by some parts where these two terms are used. I'd like to offer a sample:
Provider-Independent (PI) IP addresses/prefixes: The IP addresses/prefixes
which are used by the devices in the client's domain are owned by the
client's domain itself. If PI IP addresses/prefixes are used by a DOTS
client, then the devices managed by this DOTS client should also use
PI IP addresses/prefixes. The DOTS client can use the same PI IP
addresses/prefixes to communicate with different upstream provisioning
domains.

Provider-Aggregatable (PA) IP addresses/prefixes: The IP addresses/prefixes
which are used by the devices in the client's domain are owned by the
upstream provisioning domains. Each of upstream provisioning domains
assigns IP addresses/prefixes to the client's domain. If PA IP
addresses/prefixes are used by a DOTS client, then the devices managed
by this DOTS client should also use PA IP addresses/prefixes provided
by the same provisioning domain. DOTS clients located on the CPE should
be assigned IP addresses/prefixes by each of the upstream provisioning
domains. DOTS clients not located on the CPE may be assigned IP
addresses/prefixes only by one provisioning domain. When a DOTS client
communicates with a provisioning domain, then this DOTS client must use
the PA IP addresses/prefixes provided by this provisioning domain.



2.      In section 5.1, it describes the rule for DOTS client to choose the correct DOTS server as following:
When conveying a mitigation request to protect the attack target(s),
the DOTS client among the DOTS servers available MUST select a DOTS
server whose network has assigned the prefixes from which target
prefixes and target IP addresses are derived.

When the DOTS client can't find the correct DOTS server according to this rule, to which DOTS server should the mitigation request be sent? all DOTS servers or an arbitrary one or none? I think it's better to clarify the reasonable behavior of DOTS client in the draft.

I recommend that DOTS client don't send request to any DOTS server in such case, because sending request to all DOTS servers may inflict additional network disruption. The following sentence can be added at the end of the paragraph:
If no appropriate DOTS server can be found, then the DOTS client should not send mitigation request to any DOTS servers.



3.      In section 5.2, it describes 3 cases of deployment model. But the third case, figure 8, isn't clarified clearly enough.

3.1.      For the case of figure 6 and the case of figure 7, PI addresses and PA addresses are considered separately and explicitly. But for the case of figure 8, it doesn't mention the PI addresses or PA addresses. Is this description of the case of figure 8 suitable for both PI addresses and PA addresses? Whether or not, it's better to be clarified in the draft.

3.2.      In the case of figure 8, it describes a rule for CPE:
The CPE MUST select the appropriate source IP address when
forwarding DOTS messages received from an internal DOTS client.

But the CPE isn't a DOTS gateway in this case, how could it "select the appropriate source IP address" ? Besides, there is no description to explain what is "appropriate" in this case.



4.      In section 5.2, in the case of figure 7, it describes some complications will arise if PA addresses/prefixes are used. Although the draft says these complications are not specific to DOTS, but it doesn't clarify what should DOTS do to handle these complications.



5.      Different descriptions of PI addresses/prefixes are as followings:

The case of figure 6 describes:
Nevertheless, when PI addresses/prefixes are assigned, the DOTS
gateway MUST sent the same request to all its DOTS servers.

The case of figure 7 describes:
If PI addresses/prefixes are in use, the DOTS client can send the
mitigation request for all its PI addresses/prefixes to any one of
the DOTS servers. The use of anycast addresses is NOT RECOMMENDED.

The case of figure 9 describes:
When PI addresses/prefixes are used, DOTS clients can contact any of
the DOTS gateways to send a DOTS message. DOTS gateway will then
relay the request to the DOTS server.

I don't get the reason why the mitigation request need to be sent to all DOTS servers in the case of figure 6 but only to one of the DOTS servers in the cases of figure 7 and figure 9. I don't figure out the need of such differences.



6.      About the anycast addresses:

6.1.      There are several places in the draft saying that the use of anycast addresses is NOT RECOMMENDED, but  the reason isn't clarified. So I get confused why anycast is problematic in these cases.

For example, the cases of figure 7 and figure 9 describe that when PI addresses/prefixes are used the DOTS client can send request to any one of the DOTS servers/DOTS gateways, using anycast addresses can achieve this more easily but it is not recommended.

6.2.      Does it imply that the use of anycast addresses for DOTS servers is appropriate for those cases which don't say "anycast is not recommended"? Because not all cases describe the use of anycast addresses for DOTS servers.

For example, in the case of figure 6, it doesn't mention the anycast addresses for DOTS servers, can the anycast addresses for DOTS servers be used?



7.      In section 5.3, in the case of figure 9, it describes:
When PA addresses/prefixes are used, but no filter rules are provided
to DOTS clients, these later MUST contact all DOTS gateways
simultaneously to send a DOTS message. Upon receipt of a request by
a DOTS gateway, it MUST check whether the request is to be forwarded
upstream or be rejected.

It doesn't clarify the rule that the DOTS gateway should be according to. In which condition should the DOTS gateway forward the request or reject the request?





Best Regards

Wei Pan





> -----Original Message-----

> From: Dots [mailto:[e-mail]] On Behalf Of Roman Danyliw

> Sent: Saturday, December 01, 2018 6:31 AM

> To: [e-mail]

> Subject: [Dots] Call for adoption on draft-boucadair-dots-multihoming

>

> Hello!

>

> This is the start of a two week call for input on the WG adoption of the

> document:

>

> draft-boucadair-dots-multihoming

> https://tools.ietf.org/html/draft-boucadair-dots-multihoming-04

>

> The document has been presented and discussed at IETF 103, IETF 100 and

> IETF 99;  and revisions have been made based on WG feedback.  This

> document was created and deferred in the interest of simplifying the

> requirements and architecture drafts now getting ready for publication.

>

> At the IETF 103 meeting, there were not many participants who had read the

> draft.

>

> Please provide feedback to the list/chairs if you believe that this document

> should be adopted as a WG document.  The adoption call will end on

> December 14 2018.

>

> Regards,

> Roman and Frank

>

> _______________________________________________

> Dots mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/dots