Subject: [Dots] AD Review of draft-ietf-dots-multihoming-10

From: Roman Danyliw <[email-masked]>
Date: Tue, 8 Feb 2022 23:16:19 +0000

Hi!

I performed an AD review of draft-ietf-dots-multihoming-10.  Ben and I swapped on this document so I'll be the responsible AD from now on.  Thanks for writing these operational considerations.

The document is in good shape. I primarily have a few suggested editorial clarifications and a few places where a bit more clarity might be helpful.

** Section 5.*.  Should the diagrams or the associated text be clearer on the relationship between the CPE and the DOTS clients.  

-- For Section 5.1, C = the CPE?
-- For Section 5.2, G = the CPE?
-- For Section 5.3, G1 and G2 = the CPEs?
etc...

** Section 5.1.
   For each provisioning domain, the DOTS client MUST resolve the DOTS
   server's name provided by a provisioning domain [RFC8973] using the
   DNS servers learned from the respective provisioning domain (or the
   DNS servers associated with the interface(s) for which a DOTS server
   was explicitly configured).  

-- Editorially, given the repetition of "provisioning domain", I had trouble parting this sentence.  

-- I'm also wondering if the first step of this scenario is that the interface should provision itself per [RFC8973]?  

-- Per the guidance on resolving the DOTS server.  The options seem to be to use the DNS server the CPE learned from the network or the one configured for the interface.  The direction is clear, but I'm trying to understand the intent.  Is this trying to provide explicit guidance to not use some system wide resolver configuration?  If you don't get the DNS configuration from local policy and not from the network, I'm not sure where else if could come from.

To be concrete, does the following mean the same thing:

NEW
For each provisioning domain, the DOTS client MUST use the procedures of [RFC8973] to discover the associated DOTS server(s).  Furthermore, the DOTS client MUST resolve the DOTS server's name using either the DNS server learned from the provisioning domain or from a DNS server explicitly configured with the interface .

** Section 5.1.  
  The DOTS client SHOULD use the certificate
   provisioned by a provisioning domain to authenticate itself to the
   DOTS server(s) provided by the same provisioning domain.

Is there an automated mechanism to get this certificate being hinted at, or is this certificate provisioned by some out-of-band (and out-of-scope) mechanism?

** Section 5.1
   The DOTS client MUST be able to associate a DOTS server with each
   provisioning domain.  

The subsequent example text clarifies the intent.  On first read it seems like the normative guidance is that there must be a DOTS server with each PD.  Would the following be clearer? 

NEW:
The DOTS client MUST be able to associate a DOTS server with the provisioning domain it serves.

** Section 5.2.   
   Figure 6 illustrates a first set of DOTS sessions that can be
   established with a client-domain DOTS gateway

What are the "first set of DOTS sessions"?

** Section 5.2. Typo. s/addreses/addresses/

** Section 5.2

   The CPE MUST select the appropriate source IP address when forwarding
   DOTS messages received from an internal DOTS client.

Is this guidance specific only to Figure 6 where the gateway is present?

** Section 5.3.  Editorial.
OLD
A client-domain DOTS gateway is enabled in each CPE (rtr1, rtr2).

NEW
A client-domain DOTS gateway is enabled in each CPE (rtr1 and rtr2 per Table 1; and G1 and G2 per Figure 9).

Regards,
Roman

---

From: <[email-masked]>
Date: Wed, 9 Feb 2022 09:10:45 +0000

Hi Roman, 

Many thanks for the review. Much appreciated!

The changes can be tracked at: https://tinyurl.com/dots-multihoming-latest. 

Please see inline for more context. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots <[email-masked]> De la part de Roman Danyliw
> Envoyé : mercredi 9 février 2022 00:16
> À : [email-masked]
> Objet : [Dots] AD Review of draft-ietf-dots-multihoming-10
> 
> Hi!
> 
> I performed an AD review of draft-ietf-dots-multihoming-10.  Ben and I
> swapped on this document so I'll be the responsible AD from now on.
> Thanks for writing these operational considerations.
> 
> The document is in good shape. I primarily have a few suggested
> editorial clarifications and a few places where a bit more clarity might
> be helpful.
> 
> ** Section 5.*.  Should the diagrams or the associated text be clearer
> on the relationship between the CPE and the DOTS clients.
> 

[Med] I agree. Updated the text and the figures as appropriate. 

> -- I'm also wondering if the first step of this scenario is that the
> interface should provision itself per [RFC8973]?

[Med] RFC8973 covers also explicit configuration. The first sentence says that: assuming that a name is available from the upstream domain following the means discussed in 8973, here is what to do for resolving that name. 

> 
> -- Per the guidance on resolving the DOTS server.  The options seem to
> be to use the DNS server the CPE learned from the network or the one
> configured for the interface.  The direction is clear, but I'm trying to
> understand the intent.  Is this trying to provide explicit guidance to
> not use some system wide resolver configuration?

[Med] The text covers the specific case when the DOTS server is provided by the upstream domain. Blindly using any DNS server may lead to failure to resolve the name.  

  If you don't get the
> DNS configuration from local policy and not from the network, I'm not
> sure where else if could come from.
> 
> For each provisioning domain, the DOTS client MUST use the procedures of
> [RFC8973] to discover the associated DOTS server(s).  Furthermore, the
> DOTS client MUST resolve the DOTS server's name using either the DNS
> server learned from the provisioning domain or from a DNS server
> explicitly configured with the interface .

[Med] What about the following: 

   The DOTS client MUST resolve the DOTS server's name provided by each
   provisioning domain using either the DNS servers learned from the
   respective provisioning domain or from the DNS servers associated
   with the interface(s) for which a DOTS server was explicitly
   configured (Section 4).

Note that the pointer to Section 4 targets specifically this part:

   If a DOTS server is explicitly configured, it is assumed that an
   interface is also provided to bind the DOTS service to an
   interconnection link.  If no interface is provided, this means that
   the DOTS server can be reached via any active interface.

> Is there an automated mechanism to get this certificate being hinted at,
> or is this certificate provisioned by some out-of-band (and out-of-
> scope) mechanism?

[Med] This is out of scope. Added a note to record this.   

> The subsequent example text clarifies the intent.  On first read it
> seems like the normative guidance is that there must be a DOTS server
> with each PD.  Would the following be clearer?
> 
> NEW:

[Med] Works for me. Thanks.

> What are the "first set of DOTS sessions"?

[Med] s/first set of DOTS sessions/DOTS sessions

> ** Section 5.2. Typo. s/addreses/addresses/

[Med] Fixed.

> Is this guidance specific only to Figure 6 where the gateway is present?

[Med] This applies when the CPE does not host a dots gateway. Made this change for better clarity (merge): 

OLD: 

   For both deployments depicted in Figures 7 and 8, each DOTS client
   SHOULD be provided with policies (e.g., a prefix filter that will be
   against DDoS detection alarms) that will trigger DOTS communications
   with the DOTS servers.  Such policies will help the DOTS client to
   select the appropriate destination DOTS server.

NEW:

   For both deployments depicted in Figures 7 and 8, each DOTS client
   SHOULD be provided with policies (e.g., a prefix filter that will be
   against DDoS detection alarms) that will trigger DOTS communications
   with the DOTS servers.  Such policies will help the DOTS client to
   select the appropriate destination DOTS server.  The CPE MUST select
   the appropriate source IP address when forwarding DOTS messages
   received from an internal DOTS client.

> Table 1; and G1 and G2 per Figure 9).

[Med] Changed to: 

   o  A client-domain DOTS gateway is enabled in each CPE (rtr1 and rtr2
      per Table 1).

The link between rtrs/Gs was clarified in the updated Figure 9. 

> Regards,
> Roman
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.