Re: [Pce] WG Adoption of draft-chen-pce-bier-11

["Samuel Sidor (ssidor)" <[e-mail]>]

Hi all,

I support adoption of this draft, but I have a few minor (non-blocking) comments:

2.  Terminology
“EROO” – ERO already means “Explicit Route Object”, so why we have “Explicit Route Object Object”. Same applies to RROO vs RRO.

I would just use ERO directly same way like it is done in other PCEP RFCs/drafts.

5.  PCEP Messages

“PCRep/PCRpt message so as to indicate the
   objective function that was used by the PCE during path computation”

So PCRpt is used to indicate OF which was used by PCE in the path-computation? Is that meant in case if PCE computed path using some OF, then used PCUpdate/PCRep to indicate OF to PCC and after that PCC is including it in PCRpt towards other PCEs in the network? Is OF supposed to included in PCUpd message as well?

6.2.  The LSP Object

“…SHOULD NOT be inclueded in a…” -> typo

Also consider re-ordering description of fields to follow structure of TLV – it would be easier to find description of specific field.

TLV structure has Tunnel-ID, BFR-prefix, BFR-ID, sub-domain, but description is starting with sub-domain and ending with BFR-prefix.

6.6.  ERO Object(EROO)

“The EROO is carried within a PCRep message
   to provide the computed TE LSP if the path computation was
   successful.”

I assume that this applies to other PCEP messages (e.g. PCUpd). Also we already defined “EROO” in terminology section, so I assume that we don’t need to repeat it title.

6.6.1.  BIER-TE-ERO Subobject

“BS Length” – is this explicit length field needed to indicate length of BItString or this can be derived from subobject length?

6.7.  RRO Object(RROO)

“The PCC reports
   an BIER-TE to a PCE by sending a PCRpt message with RROO.”

So if I understood it correctly, we known that RRO will be same as ERO, ERO is mandatory in PCRpt, so we will send duplicate info in PCRpt? Is new RRO subobject really needed?

7.1.  Exchanging the BIER-TE Capability

“…BIER-TE by including the BIET-TE-PCE-
   CAPABILITY sub-TLV…” -> typo

Maybe also consider if it worth mentioning what should happen if LSP with BIER-TE PST is received, but BIER-TE PST capability was not exchanged in PCOpen

7.2.  BIER-TE-ERO Processing

“If a PCC does not support the BIER-TE PCE Capability and thus cannot
  recognize the BIER-TE-ERO or BIER-TE-RRO subobjects,The ERO and BIER-
   TE-ERO subobject processing remains as per [RFC5440].”

Shouldn’t this be really based on PST of LSP? So if BIER-TE ERO/RRO is included, then PST of that LSP MUST be BIER-TE and I assume that BIER-TE PST can be used only if it is negotiated in PST capabilities. Or are we allowing to use BIER-TE subobjects in other cases as well?

8.  IANA Considerations

“IANA is requested to make the following allocation Ifor the protocol” -> typo

Regards,
Samuel

From: Pce <[e-mail]> On Behalf Of Dhruv Dhody
Sent: Monday, September 25, 2023 6:49 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Pce] WG Adoption of draft-chen-pce-bier-11

Hi WG,

This email begins the WG adoption poll for draft-chen-pce-bier-11.

https://datatracker.ietf.org/doc/draft-chen-pce-bier/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list.

Please respond by Monday 9th Oct 2023.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien