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

[Michael McBride <[e-mail]>]

I'm not aware of any undisclosed IPR in this draft.

mike

-----Original Message-----
From: pim <[e-mail]> On Behalf Of Stig Venaas
Sent: Monday, October 25, 2021 4:57 PM
To: zhang.zheng <[e-mail]>
Cc: [e-mail]
Subject: Re: [pim] pim wg last call for draft-ietf-pim-assert-packing-02.txt

Hi 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 <[e-mail]> wrote:
>
> Hi Stig,
> Thank you very much for your comments!
> Please find my answer inline with Sandy>.
>
> ------------------原始邮件------------------
> 发件人：StigVenaas
> 收件人：
> 抄送人：[e-mail];
> 日 期 ：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) 
> <[e-mail]> 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:[e-mail]] On Behalf Of Stig Venaas
> > Sent: Saturday, September 11, 2021 4:26 AM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Cmichael.mcb
> > ride%40futurewei.com%7Cad52cf57170345a911dd08d998134c15%7C0fee8ff2a3
> > b240189c753a1d5591fedc%7C1%7C0%7C637708030944132761%7CUnknown%7CTWFp
> > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > Mn0%3D%7C1000&amp;sdata=%2BlqsSxolvaPnN2KV0tyvMdNAqqk36qNq36lTEm72dx
> > I%3D&amp;reserved=0
> _______________________________________________
> pim mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Cmichael.mcbride
> %40futurewei.com%7Cad52cf57170345a911dd08d998134c15%7C0fee8ff2a3b24018
> 9c753a1d5591fedc%7C1%7C0%7C637708030944132761%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> 000&amp;sdata=%2BlqsSxolvaPnN2KV0tyvMdNAqqk36qNq36lTEm72dxI%3D&amp;res
> erved=0

_______________________________________________
pim mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7Cad52cf57170345a911dd08d998134c15%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637708030944132761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2BlqsSxolvaPnN2KV0tyvMdNAqqk36qNq36lTEm72dxI%3D&amp;reserved=0