Subject: [Dots] Wei Pan's comments-2nd part (RE: Call for adoption on draft-boucadair-dots-multihoming)

From: <[email-masked]>
Date: Mon, 21 Jan 2019 14:13:15 +0000

Hi Wei,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Panwei (William)
Envoyé : mercredi 26 décembre 2018 11:17
À : [email-masked]
Objet : Re: [Dots] Call for adoption on draft-boucadair-dots-multihoming

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.

[Med] This is covered by this text:

"Each DOTS client is provided with policies (e.g., prefix filter) that will trigger DOTS communications with the DOTS servers."

I rearranged the text so that this statement is easily associated with both figures (7/8).

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.

[Med] Good catch. The correct behavior is the one described for Figure 6. I updated the text for figures 7/9.

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.

[Med] This is problematic because the requests won't be received by all GWs.

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?

[Med] Will add a note about this.

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?

[Med] The check is whether the target IP prefix is managed by the upstream server. Will update the text.

Best Regards

Wei Pan

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

> From: Dots [mailto:[email-masked]] On Behalf Of Roman Danyliw

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

> To: [email-masked]

> 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

> [email-masked]

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