Subject: [mpls] Comments on draft-gandhi-mpls-rfc6374-sr

From: Tarek Saad <[email-masked]>
Date: Sun, 17 Nov 2019 07:07:04 +0000

Hi authors,

Having gone over this draft, I have the following comments:

  1.  Section 6.1.1 introduces a new block number TLV. The claim is RFC8231 requires identification of block number for proper LM. From looking at RFC8231, I see the AM method can be achieved with only 2 colors and many blocks (see section 3.1 of RFC8231).. Given coloring for AM method can be done using SFL (draft-ietf-mpls-sfl-framework) with SFL labels, is this block number TLV still needed?
  2.  Section 4.3.2.1 introduces Return Path subtlv that is suposed to carry the label stack or return path: 1) a similar return path tlv is proposed in other drafts e.g. for use with BFD over SR paths, LSP ping etc. – does it make sense to have unified definition of this return path TLV? b) Figure 7B mentions Segment-List (1) to Segment-List(n) , did you mean Label(1)/Segment(1) to Label(n)/Segment(n)?
  3.  Section 8) lightly talks about ECMP and loose SIDs in end-to-end PM measurement – however, a) it is not clear how end-to-end LM is results are reliable when ECMP is present? b) Similarly, for DM when ECMP for loose SID(s) exists – how delay of each of the ECMP(s) are discovered or at least what sender is doing to ensure all ECMP(s) are traversed by probes?

Regards,
Tarek

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sun, 17 Nov 2019 13:52:15 +0000

Hi Tarek,
Many thanks for the review comments. Please see inline with <RG>…

From: Tarek Saad <[email-masked]>
Date: Sunday, November 17, 2019 at 3:07 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Comments on draft-gandhi-mpls-rfc6374-sr
Resent-From: <[email-masked]>
Resent-To: "=SMTP:rgandhi@cisco. com" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Sunday, November 17, 2019 at 3:07 PM

Hi authors,

  1.  Section 6.1.1 introduces a new block number TLV. The claim is RFC8231 requires identification of block number for proper LM. From looking at RFC8231, I see the AM method can be achieved with only 2 colors and many blocks (see section 3.1 of RFC8231).. Given coloring for AM method can be done using SFL (draft-ietf-mpls-sfl-framework) with SFL labels, is this block number TLV still needed?
<RG> The SFL is used to color the data traffic. Block number TLV is used in the probe message that collects the counter to identify the block number (e.g. color) of the counter. So the block number TLV in the probe message is still required for the counter value.

  1.  Section 4.3.2.1 introduces Return Path subtlv that is suposed to carry the label stack or return path: 1) a similar return path tlv is proposed in other drafts e.g. for use with BFD over SR paths, LSP ping etc. – does it make sense to have unified definition of this return path TLV? b) Figure 7B mentions Segment-List (1) to Segment-List(n) , did you mean Label(1)/Segment(1) to Label(n)/Segment(n)?
<RG> We had received the feedback to leverage the BFD return path TLV. We have updated the format of the TLV to match the BFD TLV structure. We still like to get separate IANA allocations for the TLV for PM.
<RG> Yes for label/segment.

  1.  Section 8) lightly talks about ECMP and loose SIDs in end-to-end PM measurement – however, a) it is not clear how end-to-end LM is results are reliable when ECMP is present? b) Similarly, for DM when ECMP for loose SID(s) exists – how delay of each of the ECMP(s) are discovered or at least what sender is doing to ensure all ECMP(s) are traversed by probes?
<RG> The ECMP hashing is used is for the delay measurement only and not for the loss measurement.
<RG> For MPLS, entropy label values can be swept to traverse the ECMP paths, i.e. use different values of the entropy labels in different probe messages for the SR Policy.

Hope these answers the questions.

Thanks,
Rakesh

Regards,
Tarek