[ippm] Re: draft-ietf-ippm-capacity-protocol-14 ietf last call Opsdir review

[[e-mail]]

Hi Ruediger,

(keeping only ippm)

Thank you.

With these changes, I think that we will need to move TR-471 to be listed as normative. Idem for Y.1540 which is required to understand algo B. 

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] <[e-mail]>
> Envoyé : mercredi 21 mai 2025 11:41
> À : [e-mail]; [e-mail]; BOUCADAIR Mohamed
> INNOV/NET <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : AW: draft-ietf-ippm-capacity-protocol-14 ietf last call
> Opsdir review
> 
> 
> Hi Tianran, hi Med,
> 
> draft version -17, which just has been published, contains added
> text to explain the pdu fields.
> 
> Regards,
> 
> Ruediger
> 
> -----Ursprüngliche Nachricht-----
> Von: Tianran Zhou via Datatracker <[e-mail]>
> Gesendet: Dienstag, 6. Mai 2025 06:05
> An: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Betreff: draft-ietf-ippm-capacity-protocol-14 ietf last call Opsdir
> review
> 
> <snip>
> 
> In general, this document is clear to me. I did not see any special
> operational or network management related issue. But there are
> several minor issues, for the authors consideration.
> 
> minor issues：
> 1. In section 5.1
> "testPort: The UDP ephemeral port number on the server that the
> client has to use for the Test Activation Request and subsequent
> Load or Status PDUs."
> Accorrding to 5.2.2, server will be assigned an UDP port after
> receiving a request. Why the request carries the server test port?
> Do you mean the client assigns the server test prot? But I am not
> sure if it's a safe mechanism.
> 
> [Authors]: CHANGE: testPort: Set to zero in the Test Setup Request
> and populated by the server in the Test Setup Response. It contains
> the UDP ephemeral port number on the server that the client has to
> use for the Test Activation Request and subsequent Load or Status
> PDUs.
> Section 5.2.2, CHANGE: ... (with the port number communicated back
> to the client in testPort field of the Test Setup Response).
> 
> --------------
> 
> 2. In section 5.1
> "maxBandwith: When this field is non-zero, it is a specification of
> the maximum bit rate the client expects to send or receive during
> the requested test. The server compares this value to its currently
> available configured limit for test admission control. This field
> MAY be used for rate-limiting the maximum rate the server should
> attempt. The maxBandwidth field's most significant bit, the
> CHSR_USDIR_BIT, is set to 0 by default to indicate
> comment："downstream" and has to be set to 1 to indicate
> "upstream"." What's the unit of the maxBandwith, bps, Bps, or Kbps
> or Mbps? I see you mentioned "bit rate". Do you indicate the bps? I
> would suggest you to make it explicitly.
> 
> [Authors]: ADD/CHANGE: maxBandwith: When this field is non-zero, it
> is a specification of the maximum bit rate the client expects to
> send or receive during the requested test in Mbps.
> 
> --------------
> 
> 3. In section 5.1
> "checkSum: An optional checksum of the entire PDU. The calculation
> is done with the fields checksum, authMode and those following
> after authMode set to zero."
> It seems the checkSum is optional. But I think it's mondatory if
> auth/encryption is not on, in order to find out bit error.
> 
> [Authors]: Section 4.5, last sentence is covering the requirement
> (indirectly, though): However, because authentication is not
> applicable to the Load PDU, the checkSum field SHALL be utilized by
> the sender whenever UDP data integrity may be uncertain (as
> outlined above).
> Section 4.5, 1st sentence CHANGE: ... header checksum that covers
> the various fields in the UDPST PDU (excluding the Payload Content
> of the Load PDU and, to be clear, also the IP- and UDP-header).
> All instances of checkSum, CHANGE: checkSum: An optional checksum
> of the entire PDU (see Section 4.5 for guidance)....
> 
> ---------------
> 
> 4. In 6.1 Client Generates Test Activation Request It seems some
> fields are not described, e.g., useOwDelVar，slowAdjThresh.
> 
> [Authors]: To make progress and save some time, we'd like to
> discuss this separately.
> 
> --------------
> 
> 5. In 7.1 Test Packet PDU and Roles
> I would suggest a dedicated section to describe the rate adjust
> algorithm. And you can describe the state machine and para config,
> so as to better understand the algorithm.
> 
> [Authors]: We'd suggest to add a reference, as algo B operation is
> standardised and published:
> Section 7.1, 7th paragraph CHANGE: The default algorithm (B, see
> [Y.1540])....
> 
> Cheers,
> Tianran
> 
> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.