[pim] Re: 1 Week short WG LC on draft-ietf-pim-light
Stig Venaas <stig@venaas.com> Mon, 09 September 2024 21:39 UTC
Return-Path: <stig@venaas.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18ECC1D5315 for <pim@ietfa.amsl.com>; Mon, 9 Sep 2024 14:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3eo04lpxmZn for <pim@ietfa.amsl.com>; Mon, 9 Sep 2024 14:39:08 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BA6C1D530D for <pim@ietf.org>; Mon, 9 Sep 2024 14:39:08 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5c3c30e663fso52433a12.1 for <pim@ietf.org>; Mon, 09 Sep 2024 14:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20230601.gappssmtp.com; s=20230601; t=1725917946; x=1726522746; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=g4lLruYILkaZuCbIzNMULUH5BTlVtwgt8/ZXtw2VT9Q=; b=R8jBdDaI7PwvrXk5FHl+1HDeGlGxRVioD6EQMpo3hCJHGv14oAbrMfZVC0bvwI9oJA 4MMJiYUqII3x9POaWhYcOV7Xoxo1uVXGOds0l4w+FBpDTjas5AqyWKbRHLYRcbMsFW8V G3IsRjFsMwIlmjgg/Er052LYAkWJj7rmb884AvHJJwHEPOJlPMp6VH8p9CBLmW7wiaNR dSZED6e2r1YhmYk+EDX5/nHi/d357qv7l2lMVGX0SY06bPAiBaanmYA3Rq4JfSToL0/W eOdhuSal+owBUc6WpvbftcT8tWAZNlFjZZL6joiFiwCT+WcrqHo4UE1Bxfq5P6TtxoTn nrAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725917946; x=1726522746; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g4lLruYILkaZuCbIzNMULUH5BTlVtwgt8/ZXtw2VT9Q=; b=kvk/1bLV4LS99yT9CFKkix0/2sAIX+bSB86wNiL5UAceWDHha+TjZS7HP/xNhkpbFe zqeW0McGA/LSliOsB/+V9CsUGDL4xzm/yNEDP7+/FgWaA1UtQExpkNxzjZqj70AH07QA z+kD8ukpuwb67gDaT88XDo+9TG5tGQYt5lry4Ayy1zPhiwDB5S9kJXswbRmIBeG38M/T pa97dx0OFJV2vAAUoaTK6gke7IGc4zqSMHQvtVV3ABaal9TN0tDI22jtlOp/gqQOHA5g dEff6lgYBlQN6rBNyWc/5PZy2Oi6yyVsaqLC4j3iqzgPtsrXfXbmXAfKLLP04tm5IuoU DQeA==
X-Forwarded-Encrypted: i=1; AJvYcCXi8PSJuDjIh2dBDsWxFDhl97DFx0FJ3w3Fts2dHi/OmQULx5LelmMm8ZmfJFc6UUZ5f6U=@ietf.org
X-Gm-Message-State: AOJu0Yw+XeeORPQycLXxc422wjXEqSYG1PNH+IW2jMOJPJ+C5jdcU3Oa L8sui8Imu7FXB/xzPRQsVguRCZorW2zy8iZcWsyHUi6KcQ6hgPGC/nOo0QC6W02ipcPA4hQ3hZC BZa947kMCNZ/g0IvXyeiEeqJM2U8v1U+Dmz/e6w==
X-Google-Smtp-Source: AGHT+IGnumEBUvFQYcVSINERJZiM4Bq/HaMb6Hzns3qfWStJ7ybwnoROpCsQj85hTr+zX5D28Zb00ER234VqmVpCOws=
X-Received: by 2002:a05:6402:348c:b0:5c2:4cbe:ac1c with SMTP id 4fb4d7f45d1cf-5c3dc779abcmr8944792a12.4.1725917945229; Mon, 09 Sep 2024 14:39:05 -0700 (PDT)
MIME-Version: 1.0
References: <20240827094719924-FmcaEPThwNgcBhDBoQrF@zte.com.cn> <ZtentCGVaLiiI9nC@faui48e.informatik.uni-erlangen.de> <CAHANBtLcWeych34Jt+vDcy-QU+X91QjRpS_bjsR3tUsa7JwP-Q@mail.gmail.com> <ZtioufuD-Iu22vBL@faui48e.informatik.uni-erlangen.de> <PH0PR08MB6581A5520DA98C1EB07330ED919C2@PH0PR08MB6581.namprd08.prod.outlook.com> <Ztn_bKSSoM7xTlUm@faui48e.informatik.uni-erlangen.de> <PH0PR08MB6581BA3D8E3DF149DAD23AEA919D2@PH0PR08MB6581.namprd08.prod.outlook.com> <Zt9ayohLFhxrKlAl@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <Zt9ayohLFhxrKlAl@faui48e.informatik.uni-erlangen.de>
From: Stig Venaas <stig@venaas.com>
Date: Mon, 09 Sep 2024 14:38:53 -0700
Message-ID: <CAHANBtJRHue03e-g6CQpRNE+x5Y-Lh0XNrbkm8fiDOKUeLtU5w@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: BA6YWRS2P27DKKF3S65C5AC2RIWFYIVK
X-Message-ID-Hash: BA6YWRS2P27DKKF3S65C5AC2RIWFYIVK
X-MailFrom: stig@venaas.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "pim@ietf.org" <pim@ietf.org>, "pim-chairs@ietf.org" <pim-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [pim] Re: 1 Week short WG LC on draft-ietf-pim-light
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/gE8wiEyk53wwR3Cab5vdBXwgoZU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>
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 <tte@cs.fau.de> 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 <tte@cs.fau.de> > > Sent: Thursday, September 5, 2024 2:59 PM > > To: Hooman Bidgoli (Nokia) <hooman.bidgoli@nokia.com> > > Cc: Stig Venaas <stig@venaas.com>; pim@ietf.org; pim-chairs@ietf.org > > 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, zhang.zheng@zte.com.cn 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: internet-drafts@ietf.org <internet-drafts@ietf.org> > > > > > > To: i-d-announce@ietf.org <i-d-announce@ietf.org>; > > > > > > Cc: pim@ietf.org <pim@ietf.org>; > > > > > > 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 -- pim@ietf.org To unsubscribe send an email to > > > > > > pim-leave@ietf.org > > > > > > > > > > > > > > > > > > > > -- > > > > > --- > > > > > tte@cs.fau.de > > > > > > > > > > _______________________________________________ > > > > > pim mailing list -- pim@ietf.org > > > > > To unsubscribe send an email to pim-leave@ietf.org > > > > > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > > > _______________________________________________ > > > pim mailing list -- pim@ietf.org > > > To unsubscribe send an email to pim-leave@ietf.org > > > > > > > -- > > --- > > tte@cs.fau.de > > -- > --- > tte@cs.fau.de > > _______________________________________________ > pim mailing list -- pim@ietf.org > To unsubscribe send an email to pim-leave@ietf.org
- [pim] 1 Week short WG LC on draft-ietf-pim-light zhang.zheng
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Stig Venaas
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Hooman Bidgoli (Nokia)
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Toerless Eckert
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Stig Venaas
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Toerless Eckert
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Hooman Bidgoli (Nokia)
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Toerless Eckert
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Hooman Bidgoli (Nokia)
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Toerless Eckert
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Stig Venaas
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Hooman Bidgoli (Nokia)
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Toerless Eckert
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Mike McBride
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… Toerless Eckert
- [pim] Re: 1 Week short WG LC on draft-ietf-pim-li… zhang.zheng