[Bier] BIER: questions on draft-ietf-pim-light / draft-ietf-bier-pim-signaling

[Toerless Eckert <[e-mail]>]

Dear BIER-WG

If you're reading PIM WG mailing list, you'll see some discuss i raised on draft-ietf-pim-light.

It seems so far nobody has identified (or documented) any use-case of that draft othrer than
as a reference for draft-ietf-bier-pim-signaling.

So i have a couple of questions / suggestions re. that use-case:

1. Q: Is there any pre-existing implementation of deployment relevance/interest of PIM over
   BIER that we should continue to consider to be compatible with in our IETF work output ?

2. I am puzzled if/why we would actually still need to write draft-ietf-bier-pim-signaling
when instead (and maybe much easier) draft-ietf-pim-light would give the PIM over BIER
use cae everything it needs.

3. AFAIK, the draft-ietf-pim-light was primarily started to remove the need to specify a
new encap for PIM messages directly into BIER. So i wonder i anyone still thinks it would
be usefulto have such a direct encap. IMHO, technically it may make BIER more complete if
it could provide signaling transport without relying on IP unicast, but then again,
the signaling such as RFC8444 also relies on IP unicast, so it seems we can not get
away in the control plane to rely on IP unicast completely... Opinions ?

4. I am not clear how important the definition of new BIER specific JP attributes
to signal the BIER "addresses" (sub-domain-id, BFR-id) is. I think it would also operationally
be simpler to expect that BFR have a separate BFR-prefix for each bier-sub-domain that
they belong to. In that case we would have a 1:1 mapping between BFR-prefix and (sub-domain-id, BFR-id),
signalled for example via RFC8444, and in result we do not need any new BIER JP extension
but draft-ietf-pim-light could provide a complete deployable solution using BIER only
as an example:

E.g.: the following could be text to allow the most simple PIM over BIER 

| If required by the underlying technology, the PIM Light LIS (Logical IP Subnet) may needs to
| provide an | address resolution between the IP interface address used in PIM signaling and the
| underlying technology for which forwarding is established, so that the receiver
| of PIM-JP message can identify the underlying technologies identity of the PIM-JP sender
| to forward / replicate traffic to it via the underlying technology.
| 
| Example 1: In BIER (RFC8279), the PIM interface address is called the BFR-prefix which
| is resolved to the BIER technologies (sub-domain-id, bfr-id) address of the PIM-JP sender
| through signaling such as [RFC8444]. BFR will need a separate BFR-prefix for each
| separate (sub-domain-id, bfr-id) for this to work.
|
| Example 2: When using RFC4875 (RSVP-TE P2MP) for the LIS, the RSVP-TE P2MP control plane can
| directly rely on the interface addreses, as address resolution (to MPLS labels) is performend
| locally within the signaling protocol RSVP-TE (label binding). 

Of course, i am not saying that we should not write draft-ietf-bier-pim-signaling for things
where we really need it, but i would hope that it would help expedient adoption of BIER if
we also allow for the most simple solutions, such as above, which would work without a
BIER specific RFC (IMHO). And add a BIER specific RFC to only amend what indeed would be BIER
specific.

5. I wonder what the opinions of BIER-WG are re. the problems of RPT/SPT switchover and
avoiding duplicates with it. From my past memory with similar problems in MVPN, i remember
that options where popular in deployment that made all PE RPs so that only (S,G) joins went
across the core. Is that still the best wisdom ? If we actually wanted to support RPT/SPT
switchover without duplicates acrosss BIER, that would require additional signaling such as
separate labels pushed onto the BIER header for RPT vs. SPT...

6. For the core question of draft-ietf-pim-light, e.g.: how to encapsulate the PIM-JP
messages. I wonder if BIER has opinions re the options:

- "native" - aka: PIM message with unicast IP header to the BFIR (EBBR) 
- IPinIP - pretty much duplicating only the inner header into an outer header

The only reason for IPinIP that comes to mind would be if we wanted to provide e.g.:
IPv4 PIM over an IPv6-unicast-only + BIER core. Theoretically, this should also be
possible with "native", because the PIM payload of an IPv6 "PIM" packet could have
IPv4 PIM-JP address elements. But i am not aware of any use of such "mixed" PIM messages
in the past, so existing PIM implementations may not like this...

Opinions ?

Thanks a lot!
    Toerless

In-Reply-To: <[e-mail]>

On Tue, Sep 10, 2024 at 07:16:10PM +0200, Toerless Eckert wrote:
> Mike, *:
> 
> This was just one aspect. My prior email had several other issues raised. Including
> for example that IMHO we should specify one or more standard encapsulations of the
> PIM-J/P messages. "Native" vs. IP in IP for example. And better text about the interface
> addresses on the LIS interface.
> 
> I also still have not received any answer what use cases we consider to be in scope:
> NBMA subnet technologies only (aka: BIER), or also broadcast technologies. We need
> to define what is in scope, and accordingly describe the issues. For example with a broadcast
> technology (EVPN/MVPN-IPMI) we would get differnt duplication issues. Aka: I would suggest
> we scope this for NBMA subnet technologies.
> 
> Also, as Homan pointed out: PIM is not the owner of at least the BIER use case,
> so i wanted to ask BIER-WG about it's opinion so that the result will best sut that
> "customer".
> 
> Does anybody herre actually represent any other use-case/customer than BIER ?
> i mentioned rfc2337, which *sob* *sob* ;-) is probably a dead technology now,
> but it did introduce he IMHO useful term LIS, so it would be a good reference.
> I think we should also mention RFC4875, because that one would benefit from PIM Light
> even more so than BIER - because by being stateful it has a lot lower scalability
> limitation (inability to build "broadcast trees for any-to-any PIM multicast
> messages).
> 
> If you want me to, i could try to propose the changed text that i think would help
> improve the document (after discuss on BIER).
> 
> Cheers
>     Toerless
> 
> On Tue, Sep 10, 2024 at 08:39:59AM -0700, Mike McBride wrote:
> > Hi Toerless,
> > 
> > So if we add this suggested text to the draft are you satisfied? If
> > so, we the authors, will confirm with Sandy that final comments are
> > addressed and she can request that Gunter continues with progressing
> > this draft.
> > 
> > thanks,
> > mike
> > 
> > On Mon, Sep 9, 2024 at 4:55 PM Toerless Eckert <[e-mail]> wrote:
> > >
> > > Thanks, Stig
> > >
> > > Yes, if one would want to do BSR it would need additional work and i agree this
> > > would be a different document. However mentioning this situation should IMHO be in this
> > > PIM Light document , so that operators know what will and what will not work with PIM Light.
> > >
> > > Aka: here is some suggested text, Happy to help edit if this is seen as appropriate:
> > >
> > > ## PIM Light and intra/interdomain PIM configuration
> > >
> > > An NBMA LIS (Logical IP Subnet) over which the PIM Light procedures
> > > are run can act as an intradomain LIS of a PIM-SM domain, or as an interdomain
> > > LIS between two or more PIM-SM domains.
> > >
> > > When PIM-SM is used for SSM ("PIM-SSM"), no further PIM considerations are needed, because except
> > > for feasible address range restrictions, no PIM difference needs to exist between intra and
> > > interdomain use of such a LIS.
> > >
> > > If PIM-SM is used with RPs intradomain, not all methods for RP discovery will work
> > > unchanged across PIM LIght LIS. Static RP configuration will work unchanged as will
> > > redundancy mechanisms MSDP (IPv4 only) and [RFC4610]. BSR [RFC5059] will not operate
> > > without enhancements, as do mechanisms relying on BSR, e.g.: [RFC8364].
> > >
> > > When PIM-SM is used with RPs and RPT/SPT switchover, (temporary) duplication of traffic between
> > > RPT and SPT traffic during switchover may occur unless a subnet technology specific mechanism is
> > > introduced that allows to avoid this. Alternatively, routers operating a PIM Light interface
> > > may be configured as RPs in an [RFC4610] (or MSDP for IPv4 only) mesh configuration, to avoid
> > > RPT operation across the PIM Light LIS.
> > >
> > > If PIM-SM is used with RPs interdomain, such deployments are subject to [RFC8815] (aka:
> > > this is in general deprecated). In those type of deployments, there is no use of RPs across the
> > > interdomain LIS, except with [RFC5059], which will work unchanged also interdomain
> > > with PIM Light.
> > >
> > > However, the setup of the NBMA LIS technology used may differ significantly between
> > > intradomain and interdomain use, as may the signalling for address resolution between
> > > the PIM interface addresses and the NBMA technology addresses. For example signaling
> > > to map BIER "addresses" (BIFT-ID, BFR-ID) to interface addresses is typically using
> > > IGP routing protocols (e.g.: OSPF via [RFC8444]), such that an interdomain deployment
> > > is not immediately feasible with it.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > On Mon, Sep 09, 2024 at 02:38:53PM -0700, Stig Venaas wrote:
> > > > Hi Toerless and Hooman
> > > >
> > > > I believe the draft needs at least some more work. I don't necessarily
> > > > agree with all that you wrote though Toerless. I might try to respond
> > > > in more detail later.
> > > >
> > > > When it comes to RP information. One option is to say that static RP
> > > > config should be used. I think that is fine. Otherwise I believe we
> > > > would need to discuss how to do BSR. BSR is certainly possible, I
> > > > think just need to relax the neighborship requirements. But if
> > > > necessary that could be a separate document, since BSR is also a
> > > > separate document.
> > > >
> > > > Regards,
> > > > Stig
> > > >
> > > > On Mon, Sep 9, 2024 at 1:31 PM Toerless Eckert <[e-mail]> wrote:
> > > > >
> > > > > On Thu, Sep 05, 2024 at 08:00:58PM +0000, Hooman Bidgoli (Nokia) wrote:
> > > > > > Hi Toerless
> > > > > >
> > > > > > I am confused why all these stuff are popping up now after 3 last calls 😊 should these type of conversations happened in past 4 years where all these decisions were made? We have been presenting this work in every single PIM session in every single IETF for past 2 years or so.
> > > > >
> > > > > Sometimes it's hard to follow all the docs. Pinging participants like me explicitly
> > > > > might have helped. But niot sure how much it help to adjucate the past.
> > > > >
> > > > > > In addition I am not 100% following your comments questions below very convoluted
> > > > > > 1.      There was a decision "by WG" to bring "PIM light" out of "pim signaling over bier" so it can be used in other use cases and network types.
> > > > >
> > > > > That's fine. And if you read my feedback, i am now questioning why we even need something
> > > > > BIER specific if this draft could be all we may need.
> > > > >
> > > > > > 2.      every one agreed on this, including yourself.
> > > > >
> > > > > Right.
> > > > >
> > > > > > 3.      PIM light is a protocol of its "own" that it so happens uses PIM-SM joins and prunes. It is not an extension. This has been very clear in the WG for the past 3 years. This was the idea.
> > > > >
> > > > > I don't think this was how i understood the conclusion. I also can not see how this interpretation
> > > > > can fly when we observe how we do need to define for e.g.: PIM-SM also how to run RP information
> > > > > across such an NBMA LIS.
> > > > >
> > > > > In the nice BIER terminoloty, what we're having here is a way how to run a PIM overlay over BIER.
> > > > > But if we want/need to split this up into differrent RFCs, then i think, we should have one RFC
> > > > > that covers all the LIS technology agnostic pieces together. Which is what this draft could/should
> > > > > be. Not jhust the join/prunes. And the dragt already starts to capture other bits and pices,
> > > > > like JP attributes, DR-behavior. Primarily the RP stuff is missing.
> > > > >
> > > > > > 4.      The use case of "pim signaling over bier" is irrelevant to this conversation. It is just an example to clarify the use case. If this is the issue that you have, you are more then welcome to come up with a text for another use case and it will be added to the draft.
> > > > >
> > > > > It's fine to use BIER as an example. One of my main questions what that we agree on a clear
> > > > > scope of this mechanism. I think that scope should best be NBMA networks. In those networks,
> > > > > the problems of broadcasted duplicates like on EVPN would be out of scope.
> > > > >
> > > > > >         a.      as per draft pim light is useful where pim can not be deployed.
> > > > >
> > > > > This is useful where multicasting of PIM protocol messaged across all members of the
> > > > > LIS is a scalability issue. I would not know another good justification.
> > > > >
> > > > > > 5.      If you have technical concerns that this draft doesn't work with in the scope that it is written in, by all means please list them clearly and we will address.
> > > > >
> > > > > I tried to do that in the prior emails very explicitly.
> > > > >
> > > > > > 6.      if you are just confused about use case that is another issue and you can refer back to the previous ietf logs/history to figure out the use case and read about "pim signling over bier" if you want to be entertained 😊
> > > > >
> > > > > I asked about 5 times here in the thread if EVPN LIS are in scope or not. Just as an
> > > > > example. WOuld i find the answer for this by goung through the history of mail exchanges ?
> > > > >
> > > > > > 7.      Reviving of "pim signaling over bier" is not a call for this WG it is a call for bier working group.
> > > > >
> > > > > Point taken. Let me bring up my argument on that WG list as well..
> > > > >
> > > > > Cheers
> > > > >     Toerless
> > > > >
> > > > > > Thanks
> > > > > > Hooman
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Toerless Eckert <[e-mail]>
> > > > > > Sent: Thursday, September 5, 2024 2:59 PM
> > > > > > To: Hooman Bidgoli (Nokia) <[e-mail]>
> > > > > > Cc: Stig Venaas <[e-mail]>; [e-mail]; [e-mail]
> > > > > > Subject: Re: [pim] Re: 1 Week short WG LC on draft-ietf-pim-light
> > > > > >
> > > > > >
> > > > > > CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 04, 2024 at 11:53:33PM +0000, Hooman Bidgoli (Nokia) wrote:
> > > > > > > Hi All
> > > > > > >
> > > > > > > Toerless I feel you have forgotten that on the last call of PIM signaling over BIER, the WG director at the time, asked us to yank out the new messages (join/prune) from that draft and come up with a new PIM "LIKE" protocol that can be used every where.
> > > > > >
> > > > > > Thanks. Would have been good to capture stuff in changelogs and also have more explanations abou the relationship to PIM BIER in this draft.
> > > > > >
> > > > > > > After the draft is completed we will use this draft in the PIM signaling over BIER and rewrite that draft pointing it to this pim light draft.
> > > > > >
> > > > > > I really prefer for us (PIM-WG) to have a sufficient understand of a whole solution before committing a component of it. So let's please have a quick discuss about what PIM BIER signaling would need to be about (given how PIM BIER signaling is almost 4 years expired):
> > > > > >
> > > > > > 1. Q: Are there already running implementations we need to take into account ? [Y/N]
> > > > > >
> > > > > > 2. Q: I take it (from your above remarks), that we should not want a PIM BIER specific encapsulation
> > > > > >    of PIM-JP messages ? [Y/N] - I think we do not need any PIM BIER specific encap (like past AD seems too).
> > > > > >
> > > > > > 3. To me, 2. means that PIM Light should discuss generic encapsulations for PIM-J/P with PIM Light.
> > > > > >    Which it currently does not. I have no strong opinions between "non-tunnel" (Unicast PIM), or
> > > > > >    IPinIP (v4/v6) or others. Given how non-tunneling alreasdy allows us to use different unicast destination
> > > > > >    addresses from upstream PIM-Neighbor field, it should be flexible enough. And its easy for e.g.;
> > > > > >    P2 switches to recognize it (IP protocol field) as PIM. In case somebody needs to snoop (e.g.: in EVPN).
> > > > > >    So i'll throw in non-encap unicast PIM-J/P as the default encap. IMHO this should also support
> > > > > >    IPv6  header with IPv4 join/prune address elements.
> > > > > >
> > > > > > 4. Wrt to PIM BIER - i really don't know why we would need that draft at all. If we take away the encap,
> > > > > >    we're left with the J/P Attributes to carry BIER information. But that seems unnecessary and maybe
> > > > > >    even "layer violation" (gasp ;-). Aka: The PIM-J/P is part of the overlay signaling, and AFAIK our
> > > > > >    past overlay signaling solutions (e.g.: MVPN) did work perfectly fine without having to include
> > > > > >    BIER specific information. In other words: The BFIR (confusingly called EBBR in BIER PIM) should
> > > > > >    be able to perfectly well figure out what BIER bits to set if the IBBR simply sends the PIM-JP
> > > > > >    with its BFR-Prefix as its IP(v6) source address. No need for additional J/P elements - tell me where
> > > > > >    my thinking is wrong if you don't agree.
> > > > > >
> > > > > > >  We just wanted a mechanism to signal joins/prunes and it so happened that we chose pim join/prune messages for this signaling. It could have been a new message but we didn't want to reinvent the wheel.
> > > > > >
> > > > > > Thats fine, no concerns about it. I am only concerned with unnecessary complexity / wheels.
> > > > > >
> > > > > > > With that said Inline HB>
> > > > > >
> > > > > > Also inline below. Cutting off unchanged stuff.
> > > > > >
> > > > > > >   PIM-SM extensions for light interface signaling (PIM light)
> > > > > > >
> > > > > > > HB> Toerless, there is no extensions here, I feel we had this conversation couple of times now. We are not extending anything, to refresh everyone's memory we wanted a new protocol that works without PIM adjacency and hellos that can signal a join or prune of a multicast route <S,G>  from one end to another end. Since the join and prune message was there already in PIM-SM we chose the same messages for PIM light. Now, it just so happens that this protocol works with PIM-SM and PIM-SSM given the considerations spelled out in the draft. Honestly I don't think we should lock this to PIM-SM or SSM because of this reasoning. We talked about this when we were debating the name at start and also while back in the BIER WG before separating the draft. If you recall in PIM over BIER we just needed 2 messages to signal a <S,G> join and <S,G> prune. This 2 messages could have any format, but it was decided that because the PIM message join and prune has the exact format that we need we just reuse it, also this is why we created the new draft to explain how this new protocol "PIM Light" works with other PIM protocols, PIM SM and PIM SSM for now. In Future we can think about PIM bidirectional etc...
> > > > > >
> > > > > > But it is just not true. If we have a PIM-SM domain on the left, and a PIM-SM domain on the right, and we connect them with PIM Light, then it is really up to the configuration of the RPs whether we are really only having a large single PIM-SM domain (same RPs on both sides), or whether we are doing interdomain PIM-SM (different RP sets. Need MSDP then - or similar).
> > > > > >
> > > > > > Yes, we can have the same nitpicking discussion about BGP as well. And we saw how much complexity it was/is to duplicate or replace all PIM-SM features in BGP.
> > > > > >
> > > > > > It is just the most simple and incremental way to understand this technology as an extension to PIM-SM IMHO.
> > > > > >
> > > > > > > HB> again I don't think it is an Extension as per above reasoning. In the draft we have explained this in introduction " PLI is useful in scenarios where multicast state needs to be signaled over networks or media that do not support or require full PIM neighborship between routers."
> > > > > >
> > > > > > And section 3.2 already shows how it's a myth to think this is not PIM, just PIM messages (IMHO).
> > > > > >
> > > > > > > HB> Of course it explains it you need to read the introduction at the
> > > > > > > HB> beginning
> > > > > > >
> > > > > > > HB> It might be desirable to simplify/upgrade some part of an existing network to BIER technology, removing any legacy multicast protocols like PIM. This simplification should be done with minimum interruption or disruption to the other parts of the network from singling, services and software upgrade point of view. To do so this draft is specifies procedures for signaling multicast join and prune messages over the BIER domain, this draft is not trying to create FULL PIM adjacency over a BIER domain between two PIM nodes. The PIM adjacency is terminated at BIER edge routers and only join/prune signaling messages are transported over the BIER network. It just so happened that this draft chose signaling messages to be in par with PIM join/prune messages. These signaling messages are forwarded upstream toward the BIER edge router on path to the Source or Rendezvous point. These signaling messages are encapsulated in a BIER header.
> > > > > >
> > > > > > Again, this is just interpretation, and i think the wrong one - given how one needs to sit down and still figure out what bits and pieces of PIM-SM are needed - and how then to configure them.
> > > > > > Any extension relying on PIM Hellos, RP configuration, Assert, DR, ...
> > > > > >
> > > > > > Calling this a PIM-SM extension makes it a lot more logical and IMHO simpler to understand and deal with.
> > > > > >
> > > > > > Also, there is no good explanation as to why this is needed in the first place. BIER could perfectly well allow you to multicast PIM-JP/Hello/Asserts, so we really need better justification IMHO.
> > > > > > I can think of some. But it really depends on how we scope its applicability.
> > > > > >
> > > > > > > Ok. See discuss above. When reading it i got the impression that it could serve as an almost complete simpler replacement of bier-pim signaling by just use unicast tunneling of those PIM-J/P.
> > > > > > >
> > > > > > > HB> Toerless again to refresh your memory and you were one of the wg members that suggested this with area director at the time. After last call on draft-ietf-bier-pim-signaling the were comments that we need to yank out the join/prune messages that is used in that draft and come up with a new protocol that explains how these join/prunes work, given that they have the same format of the PIM-SM join/prunes. This is how this draft was created, and after creating this draft we will reuse it back in PIM signaling over BIER or any where else needed.
> > > > > >
> > > > > > I hope we don't need to go back and nitpick on the exact wording of the 4 year old messages, but i am pretty sure i never meant to propose "Use PIM-SM but don't call it PIM-SM"
> > > > > >
> > > > > > > I guess if something like EVPN or WiFi is in scope, where we would not need another unicast encpsulation header, then the destination address would intentionally be unicast (e.g.: same node as JP upstream neighbor but maybe a different unicast address of the same node based on whatever routing information one uses to determine the upstream RPF neighbor).
> > > > > >
> > > > > > ... No response as to whether or not EVPN LIS are in scope or not...
> > > > > > I think it's crucial to understand whether we're talking about broadcast or NBMA LIS as scope for this work.
> > > > > >
> > > > > > Cheers
> > > > > >     Toerless
> > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > See point 9.
> > > > > > >
> > > > > > > Maybe enough discuss points to have a higher speed channel to resolve them. ...
> > > > > > >
> > > > > > > Cheers
> > > > > > >     toerless
> > > > > > > >
> > > > > > > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%25
> > > > > > > > > > 2F
> > > > > > > > > > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-pim-light%2F&data=05%7C0
> > > > > > > > > > 2%
> > > > > > > > > > 7Chooman.bidgoli%40nokia.com%7C11a211766bc54ff8b0cd08dccd108e7b%
> > > > > > > > > > 7C
> > > > > > > > > > 5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638610718244246821%7C
> > > > > > > > > > Un
> > > > > > > > > > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> > > > > > > > > > Ik
> > > > > > > > > > 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JOEnhZ0VrKhOcc4iF9pNH7M1
> > > > > > > > > > Yt
> > > > > > > > > > oU3YvyzJILiMGFMio%3D&reserved=0
> > > > > > > > > >
> > > > > > > > > > There is also an HTMLized version available at:
> > > > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%25
> > > > > > > > > > 2F
> > > > > > > > > > datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-pim-light-06&data
> > > > > > > > > > =0
> > > > > > > > > > 5%7C02%7Chooman.bidgoli%40nokia.com%7C11a211766bc54ff8b0cd08dccd
> > > > > > > > > > 10
> > > > > > > > > > 8e7b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C63861071824425
> > > > > > > > > > 15
> > > > > > > > > > 60%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > > > > > > > > > CJ
> > > > > > > > > > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=e3XXbIejFSAznwsE1
> > > > > > > > > > fg
> > > > > > > > > > BI35svzPUNqjhQfPRfpFKRfg%3D&reserved=0
> > > > > > > > > >
> > > > > > > > > > A diff from the previous version is available at:
> > > > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%25
> > > > > > > > > > 2F
> > > > > > > > > > author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-pim-light-06&
> > > > > > > > > > da
> > > > > > > > > > ta=05%7C02%7Chooman.bidgoli%40nokia.com%7C11a211766bc54ff8b0cd08
> > > > > > > > > > dc
> > > > > > > > > > cd108e7b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C6386107182
> > > > > > > > > > 44
> > > > > > > > > > 256028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > > > > > > > > > zI
> > > > > > > > > > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=11Trwovn2I4GW
> > > > > > > > > > pe
> > > > > > > > > > i9x3A%2BJSFf9z1lPgJ%2FoXssdVXncU%3D&reserved=0
> > > > > > > > > >
> > > > > > > > > > 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]
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ---
> > > > > > > [e-mail]
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > pim mailing list -- [e-mail]
> > > > > > > To unsubscribe send an email to [e-mail]
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > ---
> > > > > > [e-mail]
> > > > >
> > > > > --
> > > > > ---
> > > > > [e-mail]
> > > > >
> > > > > _______________________________________________
> > > > > pim mailing list -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > >
> > >
> > > --
> > > ---
> > > [e-mail]
> > 
> 
> -- 
> ---
> [e-mail]
> 

-- 
---
[e-mail]