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

[Toerless Eckert <[e-mail]>]

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


On Fri, Aug 17, 2018 at 10:06:27AM -0700, Stig Venaas wrote:
> Hi Toerless
> 
> Appreciate getting good feedback. The WG is way too quiet. Please see inline.
> 
> On Wed, Aug 15, 2018 at 8:25 PM, Toerless Eckert <[e-mail]> wrote:
> >
> > Had not read the document for Montreal, sorry.
> > Did not find discsussions on ML.
> 
> Yes, it's been too quiet.
> 
> > 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).
> 
> I'll get this done for sure.
> 
> > Is the example topology in figure 1 an eBGP peering ? If so, please
> > say so in text, otherwise maybe explain a bit more.
> 
> Will do.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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
> 
> > Cheers
> >     Toerless
> >
> > On Tue, Aug 14, 2018 at 01:23:36AM +0000, Michael McBride wrote:
> >> 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
> >
> >> _______________________________________________
> >> pim mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/pim
> >
> >
> > --
> > ---
> > [e-mail]
> >
> > _______________________________________________
> > pim mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pim
> 
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pim

-- 
---
[e-mail]