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

[[e-mail]]

Hi Samuel,

Many thanks for your support and helpful review. 
Please find my notes below tagged [Ran]

Best Regards,
Ran
_______________________________________________Pce mailing [e-mail]://www.ietf.org/mailman/listinfo/pce
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.
[Ran]: Indeed, I added an extra object, so the abbreviation is EROO. We will update it. Thanks.

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?
[Ran]: Yes. The OF object is carried within a PCReq/PCRpt  to indicate the required/desired objective function to be applied by  a PCE, or in a PCRep/ PCUpd to indicate the objective function that was used for path computation. Will add it.


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.
 [Ran]: Sure. 

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.
 [Ran]:  Yes.  This description will be deleted.
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?
 [Ran]:  Yes. It is explicit length field needed to indicate length of Bitstring, and this can't 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?
[Ran]:  Yes. The format of the RRO subobject is the same as that of the ERO subobject, but without the L-Flag.
According to the definition in RFC8231:
The actual path, represented by the RRO object, SHOULD be included in  a PCRpt by the PCC when the path is up or active, but it MAY be omitted if the path is down due to a signaling error or another failure.
We can add the following description:
A PCC reports an BIER-TE to a PCE by sending a PCRpt message, per [RFC8231].  The RRO on this message represents one or more adjacencies BitStrings that was applied by the PCC, that is, the actual path taken by the LSP.  The procedures of [RFC8231] with respect to the RRO apply equally to this specification without change.

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
[Ran]:  Sure. Will add it.




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?
[Ran]:  IMO, it divided into two case:
1.  When a stateful PCE sends PCUpd /PCInitiate to a PCC, it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is RSVP-TE.  If the PCC does not support the PST associated with the PCUpd or PCInitiate message, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering  path setup type) and Error-value = 1 (Unsupported path setup type)  and close the PCEP session.
2. If a PCC does not support the BIER-TE PCE Capability (e.g. support SR Capability )and thus cannot recognize the BIER-TE-ERO or BIER-TE-RRO subobjects, it will respond according to the rules for a malformed object per [RFC5440].

8.  IANA Considerations
 
“IANA is requested to make the following allocation Ifor the protocol” -> typo
[Ran]: Thanks.
Regards,
Samuel
 
From: Pce <[e-mail]> On Behalf Of Dhruv DhodySent: Monday, September 25, 2023 6:49 PMTo: [e-mail]: [e-mail]: [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