Hi Quan,
Originally we explicitly listed
From: Pce <pce-boun...@ietf.org> On Behalf Of xiong.q...@zte.com.cn
Sent: Thursday, December 14, 2023 7:53 AM
To: d...@dhruvdhody.com
Cc: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org; pce@ietf.org
Subject: Re: [Pce] WG Adoption of
draft-sidor-pce-circuit-style-pcep-extensions-05
Hi Dhruv,
I support the adoption of this draft. Thanks for the work from authors.
But I am confused about section 1 "PCEP extensions described in this document
are applicable to all Path Setup Types".
This draft mainly focus on the Circuit Style Policies and SR policy but path
setup types include RSVP-TE,SR,PCECC,SRv6, Native IP TE path and the newly
adopted BIER-TE.
I suggest that it is better to provide clarification about other path setup
types or remove this sentence.
Thanks,
Quan
<<Hi WG,
<<This email begins the WG adoption poll for
<<draft-sidor-pce-circuit-style-pcep-extensions-05.https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/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 Friday 15th Dec 2023.
<<Please be more vocal during WG polls!
<<Thanks!
<<Dhruv & Julien
--- Begin Message ---
Hi,
Can you please upload a new version of the I-D that tidies up the document in
preparation for WG adoption call?
- Limit the number of authors to 5
- Add text to the security consideration section (add references to relevant
rfcs if no new security threat is assumed)
- Think about adding a mangebility consideration
- Instead of saying that the applicability to RSVP-TE and SR-TE better yet say
it is applicable to all path setup types!
- I am confused by - "For example
Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if
there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj
SID "MAY" or "MUST"?? It should be MUST right?
- What is the way to indicate that a computed path no longer meets the original
constraints when the recomputation is blocked? Isn't that something that is
useful for operators to know?
- When the P flag is cleared or the TLV is not present, we fall back to the
existing scenario and in which one would assume PCE does the recomputation
based on various triggers yet the draft uses "MAY recompute"... could this be a
"SHOULD"?
- Add implementation Status if you have plans of implementations!
Thanks!
Dhruv
--- End Message ---
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
