[pim] Re: 1 Week short WG LC on draft-ietf-pim-light

[Stig Venaas <[e-mail]>]

Hi Toerless

Please see comments inline

On Tue, Sep 3, 2024 at 5:20 PM Toerless Eckert <[e-mail]> wrote:
>
> Sorry for not having had the time to read this earlier, and thanks for the work!
>
> Some high level councerns, suggestions:
>
> 1. Please rename this draft to something like PIM-SM/SSM light and
> write PIM-SM/SSM into abstract/beginning. Right now the exclusion of
> Bidr-PIM and PIM-DM is all the way at the end, which leaves readers
> quite puzzled.

Not sure if SSM needs to be pointed out, but PIM-SM Light might be a
better name.

> 2. The draft does not make it clear (IMHO), that PIM light is not a new/different
> method to operate PIM-SM in a network wide fashion, but instead it is a
> simplification for existing PIM-SM/SSM deployments that can be applied
> to any individual subnet and all its PIM routers - without changing
> any of the remaining aspects of the PIM-SM/SSM deployment, except for limitations
> described in this document. That seems to
> me like the most important "sales pitch" to make every reader understand
> that this is an easy improvement.

It's not really an improvement, maybe it needs stronger language to
indicate that this is only for specific cases where it is difficult to
have pim neighborships. If possible, it is preferred to use regular
PIM-SM. There is some such text in the document, but it would be good
to emphasize this.

> 3. I would strongly suggest to make this draft an update to RFC7761,
> because ultimately this is (at least IMHO), what it is. Any deployment
> of this draft needs rfc7761 plus this draft superceeding/replacing the PIM-SM
> interface procedures.

I understand why you are saying that, and perhaps it is correct. But
normally when there are updates, it is improvements that should be
considered when implementing the base spec. In this case it is not
something we should encourage people to implement, unless there are
specific scenarios making it necessary. I'm afraid people might get
the idea that this is the new better way of using pim.

> 4. PIM Join Atributes: Section 3.2.1 does not make sense to me. It pretty
> much says that senders of joins may send the new RFC5384 "Encoding Type 1",
> and the receiving router, if it does not support it, should ignore it.  Given
> how this joiner would not send Encoding Type 0, when it sends Type 1, this
> would just cause a non-working deploymen t.
>
> IMHO the correct way to do this is to say that to use RFC5384 PIM Join
> Attributes, routers need a config option on a per-PLI or better a per-PLI,neighbor
> basis indicating whether to send type 0 or type 1.

This solution needs to work together with
draft-ietf-bier-pim-signaling, the intention is for them to be
deployed together. But I realize that that draft actually uses
join-attributes! So we do indeed need to allow encoding type 1. Hence
I think we should say that type 1 must only be used if explicitly
configured to do so. Maybe we can say for BIER that all pim light
implementations with BIER encap MUST support encoding type 1 and that
it can be used without explicit configuration.

If no explicit configuration to support type 1, or not BIER encap,
then type 1 MUST not be sent, and MUST be ignored I think.

> 5. It is not clear to me if there is an actual business interest in join/prune
> attributes. If there is a good business reason to ask for it, then i would
> suggest to do so, aka: "routers supporting PLI SHOULD/MUST (pick your poison)
> also support RFC5384). I have no opinion, but given how it is explicitly included
> in the text, it sounds as if there might be interest.

As I just wrote, I think it can be optional, and require configuration
if supported since you cannot know if neighbor supports it through
hellos.

> 6. I think it would be helpfull to add more generic text to
> the introduction of 3.2 stating that any PIM-SM fucntions that without
> PLI requires signaling via PIM Hello (see https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#pim-parameters-1 - PIM Hello options) can not be supported via a PLI
> interface without explicit considerations. This draft provides such considerations
> only for a subset of these functions (e.g.: 3.2.1 for JP attributes) and 3.2.2
> for DR elections. Other functions may be possible to support via consistent
> configuration or additional signaling, but are out of scope of this document.

Sounds good.

> 7. If i understand the picture in section 3.2.2 (seriously, add a figure number!)
>  correctly, then the explanation in the section does not make sense. If the
> point of the text is to avoid that the PIM domain on the right does not
> unnecessarily gets duplicates because both D and F are sending PIM joins
> to B and/or E, then this is not resolved by "DR election" within the
> right side PIM domain (seriously, give names to those two PIM domains so you
> can call them out), but it is actually just consistent RPF selection. But
> avoiding how to get duplicate traffic into the right-side PIM domain is
> not a PLI specific issue. I would argue the same problem exists without PLI.
> So this type of consideration should at best go into an appendix.
>
> What is the actual problem with missing DR election is something you
> could not even describe with BIER:
>
>                          BBR                   BBR
>            |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
>  Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
>            |       PIM Adj|         | |         |PIM Adj       |
>            |------------( E )-------| |-------( F )----------( G )--host2
>                                           (DR Election)
>
> F sends PIM-join via PLI to E, and D sends PIM join to B. B and E
> send the same traffic. But because it's BIER, D will only receive
> the packets from B and F only the packets from E. And even if D and F
> would send PIM joins to B, the D and F would not receive "duplicates",
> but just both of them would receive the same packets, and everything
> is fine.
>
> But given how this draft is meant to NOT be BIER specific, the situation
> where is would break is something like:
>
>
>            |--PIM Domain--|- MVPN IPMI or EVPN -|--PIM domain--|
>  Source--( A )----------( B ) ---- ( S1 )---- ( D )----------( E )--host
>            |       PIM Adj|         | |         |PIM Adj       |
>            |------------( E )------( S2 )-----( F )----------( G )--host2
>                                           (DR Election)
>
> Aka: If you had a transit that behaves like a LAN, such as an EVPN
> or an MVPN IPMI, and you would try to use these PLI procedures, and
> as assumed D joins to B and F joins to E, then D would see the
> duplicate traffic from both B and E and F would do so too.
>
> But: As soon as you have a trqnsit domain that acts like an L2 domain,
> you arguably do not have a need to use PLI procedures (IMHO), but could
> do "normal" PIM procedures. BUT: If you think that PLI is useful
> in these scenarios, then it would be good to write so (even in the
> introduction, e.g.: do not only refer to BIER), and then to make
> the example about such a case. But given how the document does
> not mentioned anything but BIER, i can only speculate what you want.

I think it's safest to say that PLI must not be used with such links
unless one can say for sure that duplication cannot happen.

> 8. PIM Hello Address options
>
> The document is woefully underspecifying how to handle the PLI address.
> Does the PIM join/prune message need to include the PLI address in
> the IP destination address or only in the PIM-J/P Upstream neighbor
> address field ?
>
> Do feel confident that Unicast BGP routing information in the absence
> of MVPN BGP routing information (which i guess we would want to avoid
> using) will allow downstream routers to learn the upstream routers PLI address ?
>
> How would that work in the presence of two or more PLI interfaces - they
> would need different addrsses, so that the receiving router knows which
> PLI to assign the J/P message to. Typically, routers in BGP will only
> announce themselves with a single (router-id) address. For this reason
> we did introduce the PIM Hello option for addresses to allow mapping
> between interface addresses and routing (BGP) information addresses.
>
> So, if we fear that this will be an issue, then maybe there should be
> a section about providing such mapping information via configuration -
> if thats preferrable to waiting for a BGP extension.
>
> 9. The draft mentions draft-ietf-bier-pim-signaling, but it's totally
> unclear how its expected to relate to it. It seems to me as if this
> draft is meant to superceed draft-ietf-bier-pim-signaling by leaving
> away all the complex bits & pieces of it. But if thats the case, then
> it would be best not to refer to it.
>
> In any case, if this means the death of draft-ietf-bier-pim-signaling,
> then it would be useful to consider adding a final versin to that
> draft with appropriate explanations and then have PIM chairs change the status from
> expired to something more appropriate (after this draft becomes RFC just to be safe
> of course ;-).

This would be used together with draft-ietf-bier-pim-signaling. For
PLI to work I think you always need to be able to determine the RPF
"neighbor" address and that it should be in the JP upstream neighbor
field. For the destination address I would prefer it to be all pim
routers as usual. However, if prune override is not needed or it is a
p2p link, it could be ok to use the upstream neighbor address. Not
sure if we need to allow this. We should discuss this.
For the  BIER use-case it does not matter much what these fields are
set to, but it's good if this can work well also when there is no
encap.

> But given how even the diagram in this draft where taken from
> that pim-signaling draft, and i think the whole concept as well,
> i would ask for all the authors of that draft (unless they're also
> co-authors of this draft) to be mentioned as contributors to this
> draft.
>
> 10. I think it would be good to whip up a small section with at least a
> single "default" (SHOULD support) encapsulation for PLI traffic , so that we would not
> need yet-another-spec to know how to configure the minimum interoperable
> version of actual PLI deployment.
>
> Would simple unicasted PIM without any tunnel encpasulation suffice,
> or is it more prudent to ask for at least IPinIP with both inner and
> outer destination addresses being the PLI destination address ?

I don't think encap is needed to do PIM light, so simple unicast PIM
can suffice.

Regards,
Stig

> Cheers
>     Toerless
>
>
> On Tue, Aug 27, 2024 at 09:47:19AM +0800, [e-mail] wrote:
> > Hi,
> > Because the update content and suggestion from our AD, today begins a one-week wglc for the newest version of https://datatracker.ietf.org/doc/draft-ietf-pim-light/.
> > Please let the wg know if you think the 06 version is ready to progress.
> > Thanks,
> > Sandy
> >
> >
> >
> >
> >
> >
> > Original
> >
> >
> > From: [e-mail] <[e-mail]>
> > To: [e-mail] <[e-mail]>;
> > Cc: [e-mail] <[e-mail]>;
> > Date: 2024年08月26日 20:27
> > Subject: [pim] I-D Action: draft-ietf-pim-light-06.txt
> >
> > Internet-Draft draft-ietf-pim-light-06.txt is now available. It is a work item
> > of the Protocols for IP Multicast (PIM) WG of the IETF.
> >
> >    Title:   PIM Light
> >    Authors: Hooman Bidgoli
> >             Stig Venaas
> >             Mankamana Mishra
> >             Zhaohui Zhang
> >             Mike McBride
> >    Name:    draft-ietf-pim-light-06.txt
> >    Pages:   9
> >    Dates:   2024-08-26
> >
> > Abstract:
> >
> >    This document specifies Protocol Independent Multicast Light (PIM
> >    Light) and PIM Light Interface (PLI) which does not need PIM Hello
> >    message to accept PIM Join/Prune messages.  PLI can signal multicast
> >    states over networks that can not support full PIM neighbor
> >    discovery, as an example BIER networks that are connecting two or
> >    more PIM domains.  This document outlines the PIM Light protocol and
> >    procedures to ensure loop-free multicast traffic between two or more
> >    PIM Light routers.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-pim-light/
> >
> > There is also an HTMLized version available at:
> > https://datatracker.ietf.org/doc/html/draft-ietf-pim-light-06
> >
> > A diff from the previous version is available at:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-pim-light-06
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > pim mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> pim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]