Subject: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-conditional-ras-05: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 01 Aug 2018 00:20:31 -0700

Adam Roach has entered the following ballot position for
draft-ietf-v6ops-conditional-ras-05: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It should be noted that in IPv4 multihoming with NAT, when the egress
>  interface is chosen without taking packet source address into account
>  (as internal hosts usually have addresses from [RFC1918] space),
>  sessions can not be preserved after an uplink recovery.

This isn't necessarily true. For example, if the NAT is tracking which
ISP-facing interface is associated with a given established session, the
sessions will survive restoration of an uplink.  I have exactly such an IPv4
multi-homing configuration working on my home network (with RFC 1918 addresses
assigned to all local devices), and will happily share details of my
configuration with interested parties.

I propose striking this paragraph from the document.

---------------------------------------------------------------------------

§1:

>  general multihoming scenario for enterprise networks and proposes
>  solution which relies heavily on the rule 5.5 of the default address

Nit: "...proposes a solution..."

---------------------------------------------------------------------------

§3.2.6:

>  (as there is no preferred addresses available) and the source address

Nit: "...as there are no..."

---------------------------------------------------------------------------

§3.3:

>  into account any other uplinks properties (such as latencyetc), so

Nit: "...latency, etc.), so..."

---------------------------------------------------------------------------

§3.3.1:

>  interrupted as there is no egress path for those packets and there is
>  not return path from the Internet to the correspodning prefix.  In

Nit: "...there is no return path..."

Nit: "...corresponding..."

---------------------------------------------------------------------------

---

From: Jen Linkova <[email-masked]>
Date: Wed, 1 Aug 2018 21:55:20 +1000

Hi Adam,

> I propose striking this paragraph from the document.

Good point. I've rephrased it to
"It should be noted that in IPv4 multihoming with NAT, when the egress
   interface is chosen without taking packet source address into account
   (as internal hosts usually have addresses from [RFC1918] space),
   sessions might not be preserved after an uplink recovery unless
   packet forwarding is integrated with existing NAT sessions tracking."

https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-3.3.1

Would it address your concern?

Thanks!

(P.S. All nits fixed, thanks for pointing them out!)

-- 
SY, Jen Linkova aka Furry

---

From: Adam Roach <[email-masked]>
Date: Wed, 1 Aug 2018 11:04:06 -0500

> Would it address your concern?

It does. Thanks.

/a