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

[Toerless Eckert <[e-mail]>]

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.

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.

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.

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.

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.

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.

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.

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 ;-).

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 ?

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]