Re: [Dots] Erik Kline's Discuss on draft-ietf-dots-multihoming-11: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Erik, 

Thanks for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Erik Kline via Datatracker <[e-mail]>
> Envoyé : jeudi 21 avril 2022 07:51
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Erik Kline's Discuss on draft-ietf-dots-multihoming-11:
> (with DISCUSS and COMMENT)
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-dots-multihoming-11: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-multihoming/
> 
> 
> 
> ------------------------------------------------------------------
> ----
> DISCUSS:
> ------------------------------------------------------------------
> ----
> 
> ## Discuss
> 
> ### S5.1

[Med] Please remember that this section is about the following scenario: 

                                            +--+
                                  ----------|S1|
                                /           +--+
                               /    DOTS Server Domain #1
                              /
                        +---+/
                        | C |
                        +---+\
                         CPE  \
                               \
                                \           +--+
                                  ----------|S2|
                                            +--+
                                    DOTS Server Domain #2

       Figure 5: DOTS Associations for a Multihomed Residential CPE

> 
> * RFC 6724 source address selection is not sufficient.

[Med] It is for the scenario discussed here: communications from the multihomed border router itself, not from internal hosts.  

  Many
> complexities
>   are captured in RFC 8678.  As RFC 8475 notes, what's really
> required to
>   make this work for some nodes is proper next-hop selection in
> conjunction
>   with source address selection.  Either that, or some kind of
> source-aware
>   routing for forwarding nodes.
> 
>   For originating packets, depending on the topology, the
> following options
>   can in theory be made to work:
> 
>     * implementing RFC 6724 rule 5.5, but it's not currently
> mandatory
> 
>     * implementing RFC 6724 section 4 recommendation "that the
> candidate
>       source addresses be the set of unicast addresses assigned to
> the
>       interface that will be used to send to the destination (the
> "outgoing"
>       interface)" -- but this is highly dependent upon interface
> config
> 
>     * use of PVD Options (RFC 8801) throughout the interior (and,
> ideally, an
>       IETF-defined PVD End System model)
> 
>   I'm don't think that it's worth going into all this detail in
> this document,
>   necessarily.  You might see if a mix of references to and/or
> quotations from
>   8678, 8475, and/or mention of the issue of next-hop selection in
> conjunction
>   with source address selection yields sufficiently concise text
> to warn the
>   IPv6-multihoming-unfamiliar reader: "here be dragons (hic sunt
> dracones)".

[Med] I'm familiar with the topic (see, e.g.,  https://www.rfc-editor.org/rfc/rfc8043.html), but I don't think we need to overload the document with such pointers. Thanks. 

> 
> 
> ------------------------------------------------------------------
> ----
> COMMENT:
> ------------------------------------------------------------------
> ----
> 
> ## Comments
> 
> ### S1
> 
> * I feel like there's probably a more accurate term than
> "forking".
>   "Replicating"?  "Repeating"?
> 
 
[Med] OK, changed to "replicating". 


_________________________________________________________________________________________________________________________

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.