Subject: [pim] pim-ipv4-prefix-over-ipv6-nh WGLC

From: Michael McBride <[email-masked]>
Date: Tue, 14 Aug 2018 01:23:36 +0000

Hello folks,

Today begins a two week wglc for informational draft: https://tools.ietf.org/html/draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02. Please give it a read (it's 4 pages) and provide feedback on it's readiness to be sent to the IESG for publication. In Montreal we had 3 in favor, none against. What say you?

Thanks,
mike

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 16 Aug 2018 05:25:17 +0200

Had not read the document for Montreal, sorry.
Did not find discsussions on ML.

It would be good if one of the co-authors would do a
spell/grammer fixup on the document before passing it to IETF/IESG
review. Forces those reviewers to focus more on paylod feedback ;-))
(btw: i am bad on my own documents on this as well).

Is the example topology in figure 1 an eBGP peering ? If so, please
say so in text, otherwise maybe explain a bit more.

What would be a reason to use a setup as in the example topology,
for unicast only, e.g.: in the absence of multicast ? I can think
of two reasons only: one is that you want to avoid IPv4 address
space use, aka: make your IPv4 forwarders unnumbered on the interface
for simplifiction. The other one is that three is some form of
benefit of just having a single address familiy BGP connection.

I am asking, because as soon as you bring in IP multicast, the solution
proposes that you now must have an IPv4 address to support PIM on the
interface. And if one goal of the setup was to be unnumbered on IPv4,
then that goal would be violated. And once you do have IPv4 addressing,
its unclear to me what the benefit is to only haven an IPv6 peering
with mixed address families vs. simple separate IPv4 vs. IPv6 peerings
that match the forwrding plane.

Or the other way around: If you want to get rid of IPv4 signaling, why
then do we not better define how to send PIM joins for IPv4
groups/channels via PIM IPv6 ? If i remember it correctly, all
the address elements in PIM messages do explicitly indicate the AF
as well.

Another concern is that it may be somewhat risky to introduce this option
such a long time after the option was specified but not used. As in:
this might be a great attack vector to crash a neighboring, badly
implemented PIM neighbor acting extremely surprised seeing such an
unexpected AF. For "friedly" evolution of signaling, it might be
better to use a new code point instead.

Cheers
    Toerless

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
---
[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Fri, 17 Aug 2018 10:06:27 -0700

Hi Toerless

Appreciate getting good feedback. The WG is way too quiet. Please see inline.

> Did not find discsussions on ML.

Yes, it's been too quiet.

> (btw: i am bad on my own documents on this as well).

I'll get this done for sure.

> say so in text, otherwise maybe explain a bit more.

Will do.

> benefit of just having a single address familiy BGP connection.

Yes, it is to minimize control plane and maybe management overhead. For
whichever reason people have decided to deploy RFC 5549 for unicast, they
wish to use the reachability information for multicast. They prefer not to
change their unicast deployment to support multicast.

> the address elements in PIM messages do explicitly indicate the AF

Sure, and this is maybe something we should do. I think networks that
use 5549 would be quite happy if this was possible. This draft is just a
minor improvement to at least allow them to simplify unicast.

> better to use a new code point instead.

Note that this option is widely implemented for IPv6, so it is being used.
I doubt IPv4 implementations support it though, unless there is an AF
independent implementation that includes this in their AFI code. If they
ignore the option, then they won't be affected by this. If they did
implement it for IPv4 but don't check the AF (not that 7761 does not
require the AF to match the AF of the pim packet), then in the worst case
they end up with a list of wrong/invalid IPv4 addresses. I think this is
unlikely though, and it should not cause a crash. That one hello option
has unexpected content, should not cause a crash. If it does, then that
is a severe security issue and a broken implementation.

Finally, the use of this option is in line with 7761. It is just an
informational
document saying that it can be useful to use a different AF for the address
list option from the AF of the pim packet. Since this is already shipping, it
would be good to have it documented. And hopefully if other vendors have
customers asking for a solution for RFC 5549 deployment, they will then
consider solving it in the same way.

Thanks,
Stig

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 21 Aug 2018 23:55:44 +0200

Thanks, Stig.

So in summary, i would suggest the following refactoring of the doc::

a) context setting

Move the example tpology and explanatory text to the start of the document, call
it use-case or the like. Make the point that the solution described is
intended for operators that want to deploy only an IPv6 signaling plane (BGP)
to said neighbors, and that this solution allows them to add IP multicast
support for both address families without having to add the "wrong" address
famility unicast BG signaling, BUT: it is necessary to add a "wrong address
family interface address and to run "wrong address famility" PIM, so the
solution does not share in multicast the benefits of the original unicast-only
solultion that the operator is deploying.

That would set the context so that one can understand whats achieved and what not.

b) intended status

I think its not ideal that this is targeting informational . I think it would be
better if it was standard track and updates rfc7761. Why would this be 
informational ? 

c) Given how we make it clear in a) how this is not the ideal solution to give
operators for multicast what they want (and have with unicast), it would be
good if there was an (informational) appendix outlining what would be required
to achieve in multicast what is done in unicast: Extend PIM so that you
could send "wrong address family" address elements over the "right address family"
PIM transport. This would require IMHO some PIM Hello extension to indicate
that the node does support this option. And explain that while technically
being closer to the ultimate goal of the operator, it is not standardized
here , because it requires (a lot?) more implementation work on the PIM side
than the option described in this document. 

Cheers
    Toerless

-- 
---
[email-masked]