Subject: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

From: Stig Venaas <[email-masked]>
Date: Fri, 10 Sep 2021 13:26:09 -0700

Hi working group

As discussed in the last meeting, the chairs (Mike and I), believe
this document is ready for working group last call. No concerns were
raised in the meeting.

We are starting wglc today. Please review this document and let us
know whether you believe it is ready for publication. Please give us
any review comments you may have. In order to request publication we
will need to ensure that we have sufficient review.

This working group last call ends September 24th 2021.

Thanks,
Stig

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 11 Sep 2021 03:18:15 +0000

Hi WG,

I've reviewed this document (some nits below) and I believe it is ready for publication.

Nits:
3.4. PIM Assert Timer
Assert Timer (AT),  explain an acronym before its first use.

Thanks
Jingrong

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Saturday, September 11, 2021 4:26 AM
To: [email-masked]
Subject: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

Hi working group

As discussed in the last meeting, the chairs (Mike and I), believe this document is ready for working group last call. No concerns were raised in the meeting.

We are starting wglc today. Please review this document and let us know whether you believe it is ready for publication. Please give us any review comments you may have. In order to request publication we will need to ensure that we have sufficient review.

Thanks,
Stig

_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Huzhibo <[email-masked]>
Date: Sat, 11 Sep 2021 03:44:47 +0000

I have read this document and believe it is ready for publication.

Thanks
Zhibo Hu

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Saturday, September 11, 2021 4:26 AM
To: [email-masked]
Subject: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

Hi working group

Thanks,
Stig

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 11 Sep 2021 00:43:21 -0400

I support Publication.

Has this draft been implemented by any vendors and have any operators used
the feature?

Kind Regards

Gyan
On Fri, Sep 10, 2021 at 11:45 PM Huzhibo <[email-masked]> wrote:

> As discussed in the last meeting, the chairs (Mike and I), believe this
> document is ready for working group last call. No concerns were raised in
> the meeting.
>
> We are starting wglc today. Please review this document and let us know
> whether you believe it is ready for publication. Please give us any review
> comments you may have. In order to request publication we will need to
> ensure that we have sufficient review.
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Zhuangshunwan <[email-masked]>
Date: Sat, 11 Sep 2021 07:58:19 +0000

Hi WG,

I've reviewed this document and I believe it is ready for publication.

Thanks,
Shunwan

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Saturday, September 11, 2021 4:26 AM
To: [email-masked]
Subject: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

Hi working group

Thanks,
Stig

---

From: duanfanghong <[email-masked]>
Date: Sat, 11 Sep 2021 10:19:58 +0000

I have read this draft and support it's publication. 

Fanghong Duan

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Saturday, September 11, 2021 4:26 AM
To: [email-masked]
Subject: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

Hi working group

Thanks,
Stig

---

From: Stig Venaas <[email-masked]>
Date: Sun, 12 Sep 2021 09:22:05 -0700

Good point Gyan.

It would be great to know whether this has been implemented, and any
implementation/deployment experiences.

Thanks,
Stig

---

From: <[email-masked]>
Date: Mon, 13 Sep 2021 08:31:11 +0800 (CST)

Support the advancement of this draft as co-author. 

Thanks, 

Sandy

原始邮件

发件人：StigVenaas
收件人：[email-masked];
日 期 ：2021年09月11日 04:26
主 题 ：[pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

Hi working group

 
 
Thanks,
Stig

---

From: <[email-masked]>
Date: Mon, 13 Sep 2021 10:08:46 +0800 (CST)

------------------原始邮件------------------
发件人：StigVenaas
收件人：[email-masked];
日 期 ：2021年09月11日 04:26

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 15 Sep 2021 02:41:56 +0000

Hi WG,

This document defines a valid method to contain multiple multicast source/group info in a PIM assert packet, which could enhance scalability of multicast deployment.
Support publication.

Best
Xuesong

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Saturday, September 11, 2021 4:26 AM
To: [email-masked]
Subject: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

Hi working group

Thanks,
Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 28 Sep 2021 16:00:43 -0700

Hi authors and everyone else

Sorry for the late response from me, I have some WGLC comments that
need to be considered. Some are just editorial, but there are some
more significant comments as well. Please let me know what you think.

Abstract:
This sentence:
This document defines a standard to send and receive multiple
multicast source and group information in a single PIM assert packet
in a shared network.

It would be better to write this as:
This document defines a standard to send and receive information for
multiple multicast sources and groups in a single PIM assert packet
in a shared network.

Also, I think you can remove "in a shared network" as it is understood
from the beginning of the abstract that this only applies to a shared LAN.

Generally I think it is best to use the term "PIM assert message". We
are defining a new message type here. This message is contained in a packet,
but if fragmentation were allowed, a message could span multiple
packets. So suggest replacing "assert packet" with "assert message" throughout.

It might be good to point out that asserts may also happen on virtual
shared networks such as MVPN MDT. That is a case where I've seen issues
with huge number of asserts, perhaps good to add as a use-case in section 2.

In section 3 it says that the state machine is not changing. But then it says:
An assert winner is now responsible for
   forwarding traffic from multiple (S, G)'s out of a particular
   interface based upon the multiple (S, G)'s packed in a single
   assert.

I think this is redundant and maybe confusing. It already says that a router
may be assert winner for multiple (S,G)s. The behavior when becoming an
assert winner is not changing. This sentence may indicate that there is a
change.

In 3.1 it says:
The newly defined Hello Option is used by a router to negotiate the
assert packet packing capability. It can only be used when all PIM
routers, in the same shared LAN network, support this capability.

It is not clear what "It" refers to. Think should change to
"Assert packing can only be used..."

In 3.2:
"In this type of packing, the original assert message body is used"
Instead of "original" I think it should say that the assert message is as
defined in RFC 7761.

Section 4.1:
I think it should be possible to indicate support for both types. Hence
I think either make the length variable, so that one can send this:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OptionType = TBD         |      OptionLength = 2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Packing_Type1 | Packing_Type2 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alternatively use bits where you have just one octet, but a bit for
packing type 1, another for type 2, and allow both to be set.

I think you need to require all routers on the LAN to support a type
in order to use it. Need to explain that as part of capability negotiation.
There could be an issue where some routers only support type 1, and the
others only support type 2.

What do you think of just saying that implementations MUST always support
receiving both. But can choose to only support sending one. Then you don't
need to negotiate per type.

4.2
What does FB indicate here?

4.3:
I think you should include the full message format, including type
and subtype. I also think you will need a different subtype for the
aggregated formats. Or would you want to allow a mix of the old type
of assert records and aggregated records in the same message? In that
case you would need a way to know what type of record to expect when parsing.

How about not supporting the old style record? You woun't get optimal
packing, but it will simplify implementations and less risk of bugs.

Finally, has this been implemented already?

Regards,
Stig

---

From: <[email-masked]>
Date: Wed, 29 Sep 2021 10:30:10 +0800 (CST)

Hi Stig, 
Thank you very much for your comments! 
Please find my answer inline with Sandy>.

------------------原始邮件------------------
发件人：StigVenaas
收件人：
抄送人：[email-masked];
日 期 ：2021年09月29日 07:01
主 题 ：Re: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt
Sandy> Good suggestion. We'll update in next version. 
Sandy> Good suggestion. We'll consider to add the usecase in next version.
Sandy> We'll consider to delete this sentence in next version.
Sandy> Yes. We'll change the description in next version.
Sandy> Thanks. We'll consider to add more description. 
Sandy> FB indicates "Flag Bits" defined in RFC8736. We'll add the reference. 
of assergt records and aggregated records in the same message? In that
Sandy> Thanks. We'll consider to define the actual rules to avoid the risk of bugs. 
Sandy> Just for ZTE, we plan to implement the simple format only in further version. 
Best regards,