Re: [Bier] Initial Shepherd's comment regarding draft-ietf-bier-ping

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

HI Mankamana,

Thank you for the detailedreview and very sorry for missing the mail. All good comments. Please see inline..

Hi Authors,
This document is generally in good shape. Have few comments as part of initial shepherd review.


3.1. BIER OAM message format
Proto This field is used to define if there is any data packet immediately following the OAM payload which is used for passive Kumar, et al. Expires April 24, 2019 [Page 4] Internet-Draft BIER Ping October 2018 OAM functionality. This field is set to 0 if there is no data packet following OAM payload.

Comment: Are we expecting to have different value for proto field in future ?   Can you please add some more detail here ?

<Nagendra> This is to signal any presence of data packet following the OAM header. It is useful when any OAM functionality (such as perf measurement) needs to be inband with darta traffic.  When there is data traffic, relevant IP Proto number will be used. Since we don’t define any in this draft, we didn’t include any details other than 0.

QTF Querier Timestamp Format. When set to 2, the Timestamp Sent field is (in seconds and microseconds, according to the Initiator’s clock) in NTP format [RFC5905]. When set to 3, the timestamp format is in IEEE 1588-2008 (1588v2) Precision Time Protocol format. Any other value SHOULD be considered as sanity check

Comment: In future, do we expect some other values here ?  are we registering this field also with IANA ?

<Nagendra> I don’t think we need IANA registry for this value.

Return subcode To Be updated.

Comment: Can you please update the document ?

<Nagendra> Thanks. I wilkl update this in the next revision.

3.2. Return Code
10 DDMAP Mismatch

Comment:

  1.  Can you please add detail about what is this Return code ?

<Nagendra> Section 4.4 covers when to set this RC. A snip below:


“If the BitString in Header-H does not match the BitString in

      Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to

      "DDMAP Mismatch" and go to section 4.5<https://tools.ietf.org/html/draft-ietf-bier-ping-04#section-4.5>.  When there are more than

      one DDMAP TLV in the received Request packet, the Downstream

      Address and Downstream Interface Address should be matched with

      Interface-I to identify the right DDMAP TLV and then perform the

      BitString match.

“

Please let me know if this clarifies.


  1.  If TTL expires, what would be return code used by intermediate node ?

<Nagendra> TTL expiry does not need a new return code. This is a mechanism used to force a CPU punt for the OAM packet in a transit node. Depending on the processing, different return code will be used.

When I flag is set, the Responding BFR SHOULD include the Incoming SI-BitString TLV in Echo Reply message.
Comment :  I think MUST would be more appropriate instead of SHOULD here ?

<Nagendra> Ok. This can be changed.

3.3.4.1.1. Multipath Entropy Data
Comment: Here M flag is using left most bit where as I was in previous section using right most bit of flag.  Should it also not be right most bit ?

<Nagendra> This TLV is a variable length field and the size varies depending on the type of entropy. So I think it is appropriate to use the left most bit.

4. Procedures This section describes aspects of Ping and traceroute operations. While this document explains the behavior when Reply mode is "Reply via BIER packet", the future version will be updated with details about the format when the reply mode is "Reply via IP/UDP packet".
Comment: Does it mean, new document in future ? or this document is going to get updated more ?

<Nagendra> Thanks for catching.

[RFC8296] proposes the BIER header with Entropy field that can be leveraged to exercise all ECMP paths. The Initiator/BFIR will use traceroute message to query each hop about the Entropy information for each downstream paths. To avoid complexity, it is suggested that the ECMP query is performed per BFER by carrying required information in BIER OAM message.

Comment: Is this document not talking only about Ping ? I see some mention of Traceroute in document.  If traceroute procedure is also expected to be in this document, can we add some moreo detail about procedure ?

<Nagendra> This document explains both ping and trace. The procedure pretty much covers the same. If you think something is missing for traceroute, do let us know.

4.4. Receiving BIER Echo Request Sending a BIER OAM Echo Request to control plane for payload processing is triggered as mentioned in section 4.1. Any BFR on receiving Echo Request MUST send Echo Reply with Return Code set to "Malformed Echo Request received", if the packet fails sanity check. If the packet sanity check is fine, it SHOULD initiate the below set of variables:
Comment: Can you please add detail about what sanity check we are talking here ?

<Nagendra> sure. I will add more details about the sanity check.

4.5. Sending Echo Reply If Reply-Flag=0; BFR MUST release the variables and MUST not send any response to the Initiator. If Reply-Flag=1, proceed as below:
Comment: You might want to consider to have subsection of each reply-flag.

<Nagendra> It is a local variable that is initialized to 1 and may change during the probe processing. This flag instructs if the node should respond to initiator or ignore. If the flag is set to 0 (while processing the probe as defined in section 4.x), there will be no response and if it is set, it follows section 4.5. So I think we don’t need sub sections as there is nothing much for the responder to do when the flag is set to 0.

Once again, thanks a lot for the detailed comments. I will update the same in the next version.

Thanks,
Nagendra


Thanks
Mankamana