Subject: Re: [RTG-DIR] review of draft-ietf-6man-multi-homed-host-07

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 4 Aug 2016 11:49:10 +0000

[Adding the authors and th eIESG.]

Thanks Chris!

On 8/3/16, 9:29 PM, "rtg-dir on behalf of Chris Bowers"
<[email-masked] on behalf of [email-masked]> wrote:

>The following is a review of draft-ietf-6man-multi-homed-host-07, with an
>emphasis on aspects related to the Routing Area.
>
>draft-ietf-6man-multi-homed-host-07
>Title: Routing packets from hosts in a multi-prefix network
>                  
>Major issue 1)
>It does not seem appropriate for a document from 6man in the Internet
>Area to make a normative statement about what routing protocols should
>implement.
>
>The Routing Area is actively addressing routing aspects of PA
>multi-homing, and I-D.ietf-rtgwg-dst-src-routing may eventually be part
>of a solution, but it is premature to bless that approach, especially in
>this document.  
>
>-----
>Existing text:
>2.2.  Expectations of multihomed networks
>
>   The direct implication of Section 2.1 is that, if the network uses a
>   routing protocol, the routing protocols used in multihomed networks
>   SHOULD implement source-prefix based egress routing, for example as
>   described in [I-D.ietf-rtgwg-dst-src-routing].
>------
>Proposed text:
>2.2.  Expectations of multihomed networks
>
>In a multihomed network, when a router advertises a PIO to a host,
>the host should expect that when it sends a packet to that router with a
>source
>-----
>
>The current title of this draft could be taken to mean that this draft
>has a broader scope than it does.
>A more accurate title might be:
>"First-hop router selection by hosts in a multi-prefix network"
>address corresponding to that PIO, the packet will get routed to the
>correct ISP.  
>
>=====
>Major issue 2)
>The text in Section 3.1 and 3.2 should be made clearer, so that an
>implementer knows what exactly is being modified.
>
>2a) These sections are intended to modify how hosts should interpret PIOs
>and RIOs advertised by routers in selecting the first-hop router to send
>a given packet to. However, it is unclear how a host should take into
>account the Default Router Preference value in selecting the first hop.
>For example, suppose a host receives PIO for source prefix A from router
>1 with Default Router Preference set to Low, and it receives PIO for
>source prefix B from router 2 with Default Router Preference set to High.
> It is unclear what first-hop router the host should use when sending a
>packet with source address in prefix A in this case.  Does the matching
>source prefix or the higher Default Router Preference take precedence?
>
>2b) The abstract and header material say that draft is intended to update
>RFC4861.  The text in these sections should be more explicit about the
>exact text in RFC4861 that needs to be updated.
>
>2c) This draft also seems to be updating RFC4191.  If so, that should be
>explicitly stated, and this draft should make it clear what text in
>RFC4191 needs to be modified.  RFC4191 defines three types of hosts (A,
>B, and C).  Does this update apply to all of the host types?
>
>Other issues:
>=============
>Abstract:
>
>Current text:
>This host behavior may interact with source address
>   selection in a given implementation, but logically follows it.
>
>I find this sentence confusing.
>
>Proposed text:  
>Host behavior in choosing a first-hop router may interact with
>source address selection in a given implementation.  However,
>the selection of the source address for a packet is done before
>the first-hop router for that packet is chosen.
>==============
>
>Section 2.1 has the following text:
>
>   In some circumstances both L and A might be zero.  If SLAAC is not
>   wanted (A=0) and there is no reason to announce an on-link prefix
>   (L=0), a PIO SHOULD be sent to inform hosts that the prefix is
>   source-routed by the router in question.
>
>I don't think that sending a PIO should be interpreted by the host to
>mean that "the prefix is source-routed by the router in question".  The
>reason for the router to make the PIO advertisement is so that the host
>uses that router as its first hop for packets with a source address in
>the PIO prefix.  I don't think we want the host to assume any more than
>that.  
>
>Proposed text:
>   In some circumstances both L and A might be zero.  If SLAAC is not
>   wanted (A=0) and there is no reason to announce an on-link prefix
>   (L=0), a PIO SHOULD be sent to inform hosts that they should use  the
>   Router in question as the first-hop for packets with source addresses
>    in the PIO prefix.
> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 4 Aug 2016 13:10:19 +0000

Hi Alvaro,
   Given that this review came in two hours before the telechat, I think it 
is highly unlikely that the issues raised can be addressed before then 
(especially due to the timezones of the authors). A quick read suggests to me 
that the main issues from the review echo the ones Alia and you raised. How 
do you want to proceed? Do you still want to discuss the document in the 
telechat or would you like to Defer this?

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Aug 2016 09:00:19 +1200

>>> the host should expect that when it sends a packet to that router with a

I prefer to leave the reference, but we have already recognized that the upper
case SHOULD is inappropriate.

>>> address corresponding to that PIO, the packet will get routed to the

No objection.

>>> source prefix or the higher Default Router Preference take precedence?

The matching source prefix wins. That is the second sentence of 3.2:
"Routers that have advertised the prefix in its Router Advertisement
message SHOULD be preferred over routers that do not advertise the
prefix." We could add "regardless of Default Router Preference".

>>> exact text in RFC4861 that needs to be updated.

Disagree. We clearly identify the sections of 4861 whose implementation
is affected. But the nature of the additional code is highly dependent on
the way RFC 4861 is implemented (e.g. what data structures are used) and in
particular on whether rule 5.5 of RFC 6724 is implemented. Textual updates
to 4861 would just be confusing.

>>> B, and C).  Does this update apply to all of the host types?

Disagree. As far as I know, we are not changing the handling of RIOs. In fact,
I'm not even sure 4191 needs to be a normative reference.

>>> Other issues:

OK

OK

  Brian

---

From: Chris Bowers <[email-masked]>
Date: Thu, 4 Aug 2016 22:05:41 +0000

Brian,

Thanks.  See inline with [CB].

Chris

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, August 04, 2016 4:00 PM
To: Suresh Krishnan <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; Chris Bowers <[email-masked]>; [email-masked]
Cc: <[email-masked]> <[email-masked]>; [email-masked]; Alia Atlas <[email-masked]>; [email-masked]
Subject: Re: [RTG-DIR] review of draft-ietf-6man-multi-homed-host-07

No objection.

=======
[CB] As it stands, I think the current text is quite confusing.  I think it would be 
worthwhile to make an attempt to explicit modify the text 
of RFC4861 and then decide which version is less confusing.  
=======

======
[CB] Section 3.1 explicitly says that the interpretation of RIOs is modified.
  
                                               In a multi-homed network implementing
   source/destination routing, the interpretation of default router or
   an RIO has to be modified with the words "if the source address is in
   one of the prefixes I advertise in a PIO".

So I think the fact that this updates RFC 4191 needs to be stated and the 
draft should make it clear what text in RFC4191 needs to be modified.
======

OK

OK

  Brian