Hi Samuel,
Many thanks for review. It is good suggestion to explicity mention the use of
BS length.
Best Regards,
Ran
Original
From: SamuelSidor(ssidor) <ssi...@cisco.com>
To: 陈然00080434;
Cc: pce@ietf.org <pce@ietf.org>;
Date: 2023年10月10日 16:23
Subject: RE: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11
Hi Ran,
Thanks a lot, for responses. Agreed on all points.
For BS Length, if added value of that field is the use on other places (BIER
header), maybe just consider mentioning that usage explicitly in the draft.
Regards,
Samuel
From: chen....@zte.com.cn <chen....@zte.com.cn>
Sent: Tuesday, October 10, 2023 4:47 AM
To: Samuel Sidor (ssidor) <ssi...@cisco.com>
Cc: pce@ietf.org
Subject: Re: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11
Hi Samuel,
Thank you very much for your quick reply. Please find my notes below tagged
[Ran].
Best Regards,
Ran
Original
From: SamuelSidor(ssidor) <ssi...@cisco.com>
To: 陈然00080434;
Cc: pce@ietf.org <pce@ietf.org>;
Date: 2023年10月09日 16:46
Subject: RE: Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11
Hi Ran,
Thanks a lot for your responses. Please see inline responses marked with
[Samuel]
Thanks,
Samuel
From: chen....@zte.com.cn <chen....@zte.com.cn>
Sent: Sunday, October 8, 2023 11:28 AM
To: Samuel Sidor (ssidor) <ssi...@cisco.com>
Cc: pce@ietf.org
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
Pce@ietf.org
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.
[Ran]: Yes, I agree. In this way, we can deduce it. Another thing to consider
is BSL is not only used to display bitstring length, BSL is important
information for BIER. BSL is also used when encapsulating the BIER header.
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.
[Ran]: OK. Thanks.
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.
[Ran]: Yes, that's right. This is a bit misleading.“BIER-TE PCE Capability
TLV”is used mainly to retain the names used in previous standards, such as:
Stateful-PCE-Capability TLV (RFC 8281), SR-PCE-CAPABILITY sub-TLV (RFC8664),
etc.
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 Dhody
Sent: Monday, September 25, 2023 6:49 PM
To: pce@ietf.org
Cc: draft-chen-pce-b...@ietf.org
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
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce