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

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

Hi Ran,

Thanks a lot for your responses. Please see inline responses marked with [Samuel]

Thanks,
Samuel

From: [e-mail] <[e-mail]>
Sent: Sunday, October 8, 2023 11:28 AM
To: Samuel Sidor (ssidor) <[e-mail]>
Cc: [e-mail]
Subject: Re: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11


Hi Samuel,



Many thanks for your support and helpful review.

Please find my notes below tagged [Ran]



Best Regards,

Ran

_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://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.
[Samuel]Is there any reason why it cannot be derived? I thought that only variable part of BIER ERO subobjects is BitString. If I know length of complete subobject (8+ bytes) and I have 1 field with variable length and rest of fields with fixed length (4 bytes), then it should not be hard to get length of Bitstring (Length – 4 bytes). Same way like you now defined, then value 1 means 64 bits, then you can just say that 8 bytes long “Adjacency BitString” means 64bits,… Anyway, I’m fine with explicit field, I just thought that it may be possible to optimize.

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.

[Samuel] I copied only part of the statement, but I was more talking about that section in general:
   For the integrity of the protocol, we define a new BIER-TE-RRO
   object, but its actual value is consistent with ERO.  The PCC reports
   an BIER-TE to a PCE by sending a PCRpt message with RROO.

And I was thinking about dropping definition of RRO subobject completely as it has no added value (it contains duplicate information in PCRpt based on this statement). But I agree that RFC8231 still requires RRO as “logical delimiter” between actual and requested attributes, so we cannot just skip that object and having some special behavior just for BIER-TE would be probably not ideal.

I’m fine with your proposed description.

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].

[Samuel]

#1 – Ack. Both PCC and PCE should already know about supported PST from “Path Setup Type Capability”, so ideally PCEP peer should not even send such PCUpd/PCInitiate message, because it knows already whether it is supported or not.

#2 – Sure, so no PST and no BIER-TE capability advertised in PCOpen and no PST in LSP, but still BIER-TE ERO or RRO included.

One more question for name of this TLV-  “BIER-TE PCE Capability TLV”, why it is PCE capability TLV? It is supposed to be used by PCC as well, right? (I know that such naming was used in some other drafts/RFCs, but it is a bit misleading.

8.  IANA Considerations



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

[Ran]: Thanks.

Regards,

Samuel



From: Pce <[e-mail]<mailto:[e-mail]>> On Behalf Of Dhruv Dhody
Sent: Monday, September 25, 2023 6:49 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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