Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

Hi David,

Seeing this now, it appears that your post arrived while I was in the process
of composing my own post. But, to respond to your points:

Ø  I don't think you can just plop that in there without at least some revisions to section 4 as well

You are right – section 4 also needs to say something (see my post).

Ø  Thinking about this a bit, I think you are referring to redirects in general and your draft 'draft-templin-6man-rio-redirect' more specifically.

I am referring to Redirects in general; my draft is based on standard Redirects but simply
asks them to carry a bit more information.

Ø  In a current unmodified host only individual addresses and not whole prefixes can be redirected

True.

Ø  and therefore the router would have to track individual addresses to redirect them, which again break the premise of reducing ND.

Redirects are issued at the discretion of the first-hop router. If Redirects are not appropriate
for the link, or if the first-hop router just plain doesn’t want to send them, then it need not
send them. But, there will be some links (e.g., NBMA) on which Redirects provide a strong
operational advantage.

Ø  Once redirects for whole prefixes are commonly available then at the discretion of the router you could do as you suggest

No, it is about Redirects in general and not just prefix Redirects.

Ø  While I like the ideas in 'draft-templin-6man-rio-redirect' they are not generally implement in the vast majority of hosts today, and therefore networks implementing 'draft-ietf-v6ops-unique-ipv6-prefix-per-host' can't reasonably expect the capability to be available, and can only reasonably expect redirects for individual addresses, and implementing peer-to-peer communication on that basis is not compatible with the fundamental expectation in 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

On some links, Redirects for even individual addresses provide a useful optimization
and should not be disallowed. As far as I can tell, this is the only point on which
‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’ unnecessarily limits the domain
of applicability.

Ø  Once the capabilities described in 'draft-templin-6man-rio-redirect' are generally available, I think it would be reasonable to add an option for peer-to-peer communication to a future revision of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', but based on the capabilities available today you can't implement peer-to-peer communications without violating other fundamental expectations in draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

There is no need to wait for ‘draft-templin-6man-rio-redirect’ if we can get this
right on the first iteration of ‘draft-ietf-v6ops-unique-ipv6-prefix-per-host’. As
you know, BCPs are intended for the long-term and are not easy to update
once they are published.

Thanks - Fred

From: David Farmer [mailto:farmer@umn.edu]
Sent: Friday, August 25, 2017 7:53 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

I don't think you can just plop that in there without at least some revisions to section 4 as well.

Thinking about this a bit, I think you are referring to redirects in general and your draft 'draft-templin-6man-rio-redirect' more specifically. In a current unmodified host only individual addresses and not whole prefixes can be redirected, and therefore the router would have to track individual addresses to redirect them, which again break the premise of reducing ND.  Once redirects for whole prefixes are commonly available then at the discretion of the router you could do as you suggest.

While I like the ideas in 'draft-templin-6man-rio-redirect' they are not generally implement in the vast majority of hosts today, and therefore networks implementing 'draft-ietf-v6ops-unique-ipv6-prefix-per-host' can't reasonably expect the capability to be available, and can only reasonably expect redirects for individual addresses, and implementing peer-to-peer communication on that basis is not compatible with the fundamental expectation in 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

Once the capabilities described in 'draft-templin-6man-rio-redirect' are generally available, I think it would be reasonable to add an option for peer-to-peer communication to a future revision of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', but based on the capabilities available today you can't implement peer-to-peer communications without violating other fundamental expectations in draft-ietf-v6ops-unique-ipv6-prefix-per-host'.

Thanks.

On Thu, Aug 24, 2017 at 12:37 PM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
In section 2, the document says:

   " o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router"

Please change to say:

   "o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router unless the shared network
      explicitly permits peer-to-peer operations"

Thanks - Fred
fred.l.templin@boeing.com<mailto:fred.l.templin@boeing.com>

_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops

--
===============================================
David Farmer               Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815<tel:(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel:(612)%20812-9952>
===============================================