Hi Samuel,
Many thanks for your support and helpful review.
Please find my notes below tagged [Ran]
Best Regards,
Ran
_______________________________________________Pce mailing
listPce@ietf.orghttps://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 <pce-boun...@ietf.org> On Behalf Of Dhruv DhodySent: Monday,
September 25, 2023 6:49 PMTo: pce@ietf.orgCc:
draft-chen-pce-bier@ietf.orgSubject: [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
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
