Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Cheng and Dhruv,

Thanks a lot for all the explanations and the revised I-D.

I sincerely think that the document has been improved with those changes.

Regards

-éric

From: Cheng Li <[e-mail]>
Date: Thursday, 4 April 2024 at 17:45
To: Dhruv Dhody <[e-mail]>, Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)
Thanks Eric and Dhruv for your comments.

Please see my reply inline.
We also updated the drat accordingly to address your comments, please check,


HTML:     https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-25.html

HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6

Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-25

Thanks,
Cheng


From: Dhruv Dhody <[e-mail]>
Sent: Thursday, April 4, 2024 8:14 AM
To: Éric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)

Hi Éric,

On Thu, Apr 4, 2024 at 12:53 AM Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-pce-segment-routing-ipv6-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-ipv6-23

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Hariharan Ananthakrishnan for the shepherd's write-up
including the WG consensus and the justification of the intended status.

Other thanks to Bob Halley, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-pce-segment-routing-ipv6-22-intdir-telechat-halley-2024-02-24/
(Bob found no issue)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Title

The title is rather long, should it rather use "IPv6 Segment Routing"
[Cheng]Ack
## Abstract

Like other IESG members, I find the abstract convoluted, i.e., please be
straight to the point and focus on SRv6 and PCEP, e.g., no need to mention LDP
in the abstract.
[Cheng]Ack.

## Section 1

The second paragraph is rather useless, with another mention of SR-MPLS in a
SRv6 document. The 3rd paragraph is not that useful either.

4th and 5th paragraphs could be used during the WG call for adoption, but have
little to do in a SRv6-related document. Please really consider to change this
section.

Dhruv: I see your point for the 2nd and 3rd paragraph. For 4th and 5th, it is important to highlight what is the base set of specifications over which this extension is built.
[Cheng]I am ok with deleting the 2nd and 3rd paragraph, though I think they may be helpful for some readers who are not familiar with SR. But it is ok to delete.
I am not really sure of the long history in PCE WG, but for most of the RFCs in the WG, they explains the dependent RFCs/Tech in a detailed way, which can help readers to understand the logic and the base of this RFC. I will suggest to keep them.


## Section 2

Consider adding a reference to the SRH RFC.

## Section 3

Is `subobject` term well-defined ? Honestly, I never read this term before and
even if I can *guess* the meaning, it may be worth adding it to the terminology
section.

Dhruv: They go back to the base specification of PCEP in RFC 5440 as well as RSVP-TE in RFC 3209 and thus are well known and understood.  One can add this sentence to make it clear - "In PCEP messages,route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects."
[Cheng]agree with the modification.


## Section 3.1

I have *very hard* time to understand what is meant by `When SR-MPLS is used
with an IPv6 network` to be honest. I was about to ballot a blocking DISCUSS on
this point, but I assume that I simply lack the PCEP context. May I
***REQUEST*** some explanations here ?

Dhruv: I suggested that text based on Jim's comment. Maybe you can help with wordsmithing this :)
In an IPv6-only network that uses SR-MPLS, the SR related information in the IGP/BGP will use an IPv6 address and the data-plane would use MPLS. In this case, for PCEP the RFC 8664 (SR-MPLS extension) is sufficient and there is no role of SRv6 here.

Would the term "IPv6-enabled networks (IPv6-only or Dual-stack networks)" be better?
[Cheng]Though I know what you are saying here, but I will rather remove this paragraph, because it is not so needed at all. Regarding using SR-MPLS in an IPv6 network, no matter, using IPv6 in the control plane or using SR-MPLS as the tunnel of IPv6 payload, that should be handled in RFC8664, not this draft, so I will delete this paragraph. Please see if it is ok for you




## Section 4.1.1

Is there a reason why the only defined bit in the flag field it not the
rightmost one ?

Dhruv: There used to be another flag "X" that we removed later on. Implementers preferred not to move the N flag from its current position.
[Cheng]Indeed

Please mention the position of the N bit (bit 30 from picture but let's be
crystal clear).
[Cheng]Ack

Is it common for PCEP communication to use the term TLV where the Length is not
actually the field length ? How can a non SRv6 capable PCEP speakers will
parse/skip this TLV without prior knowledge of the 4-octet alignment ?

Dhruv: The (MSD-Type,MSD-Value) are not called TLV, they are a part of the value portion of SRv6-PCE-CAPABILITY sub-TLV. The SRv6-PCE-CAPABILITY has type (27) and a length field and follows the TLV format. The length field will indicate how many pairs of (MSD-Type,MSD-Value) are included. Am I misunderstanding your comment?
[Cheng]no comment here. Please see Dhurv’s reply


## Section 4.3.1

No need to reply, but the encoding of TLV object is really weird again as it
starts with an important flag and the length is now only 1 octet.

Dhruv: This is not a TLV but a subobject. They follows the standard subobject encoding that PCEP inherited from RSVP-TE - https://datatracker.ietf.org/doc/html/rfc3209#section-4.3.3


Isn't it weird that S&V flags indicate an absence and T flag a presence ?

Dhruv: We borrowed the S and F flag from RFC 8664. I guess we could have kept them uniform :( but it's late to make a change now.


Should there be a reference to the IANA registry already here ?

## Section 4.3.1.2

`The presence of each of them ` should probably be "presence or absence" cfr my
comment above.

Dhruv: Agree.

Thanks!
Dhruv