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

From: Yisong Liu<[email-masked]>
Date: 26 Oct 2021 12:28:52 +0800

Hi Stig

I am not aware any undisclosed IPR of the document as co-author.

Best Regards

Yisong

发件人: Stig Venaas

时间: 2021/10/26(星期二)07:56

收件人: zhang.zheng;

抄送人: pim;

主题: Re: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txtHi Sandy

Thanks for posting a new revision. I think there still might be a few
things that need to be improved, but we are getting there.

Also, I need each of the authors to state whether they are aware of
any IPR other than what has been disclosed. Also if anyone else is
aware of any IPR related to this, let us know.

Here are the minor issues I see in the latest version.

In the introduction it says:
It can efficiently pack multiple PIM assert packets
I think should change it to say assert messages.

In 2.6:
In the above scenarios, the existence of PIM assert process depends
I think it should say "assert state depends", or?
It also says
packets trigger PIM assert process in the shared LAN networks
should it be "assert processing in the..."?

In section 4: it says
The messages follow the same transmission order as the messages
defined in [RFC7761].
I'm not sure what this means.

In 4.1 it says:

   The node may support multiple packing types. The node MAY set all
   the associated bits when it sends PIM Hello message. The packing
   type selected in the LAN MUST be supported by all the nodes. When
   all the nodes all support multiple packing types, the simple packing
   format type SHOULD be selected. For example, when all the nodes in a
   LAN advertise that they support both type 1 and type 2, type 1
   should be selected for packing.

Do you really want to prefer type 1 if both are supported? Don't you
want to take advantage of the format in 2 when all routers support
that and many routes have the same RP or the same source? I think you
can leave the choice to the implementation. The main requirement is
that a given type should never be used unless all routers support the
specific type.

You have some text such as this:
       For simple packing format, the SubType field is set to 1 (To be
       assigned by IANA).

It would be better to just say that it is assigned by IANA. I think it
might be a good idea to change this text:

   Type
       The new Assert Type values TBD1.

to say
   Type.SubType
       The new Assert Type.SubType value TBD1.

IANA assigns Type.SubType as a single extended type value. Which
subtype you will get will depend on which order IANA is assigning the
new values. It depends whether there are other drafts also getting
assignments.

Regards,
Stig

On Tue, Sep 28, 2021 at 7:30 PM <[email-masked]> wrote:
>
> 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
> 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.
> Sandy> Good suggestion. We'll update in next version.
> 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.
> Sandy> Good suggestion. We'll consider to add the usecase in next version.
> 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.
> Sandy> We'll consider to delete this sentence in next version.
> 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.
> Sandy> Yes. We'll change the description in next version.
> 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.
> Sandy> Thanks. We'll consider to add more description.
> 4.2
> What does FB indicate here?
> Sandy> FB indicates "Flag Bits" defined in RFC8736. We'll add the reference.
> 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 assergt 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.
> Sandy> Thanks. We'll consider to define the actual rules to avoid the risk of bugs.
> Finally, has this been implemented already?
> Sandy> Just for ZTE, we plan to implement the simple format only in further version.
> Best regards,
> Sandy
> Regards,
> Stig
> On Tue, Sep 14, 2021 at 7:42 PM Gengxuesong (Geng Xuesong)
> <[email-masked]> wrote:
> >
> > 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
> >
> > 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
> >
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pim
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

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