Hi Giuseppe,
I have a question about your statement:
But if nodes on the path do not support some capabilities, it is not a big
issue. Indeed, both Alternate Marking and IOAM documents specify that nodes
that do not support a specific functionality will forward the packet
without any changes to
Hi， all，
I support the adoption of this document. Thanks.
Chongfeng
On Fri, Jun 24, 2022 at 4:59 AM Dhruv Dhody wrote:
Hi WG,
This email begins the WG adoption poll for draft-chen-pce-pcep-ifit-06.
https://datatracker.ietf.org/doc/draft-chen-pce-pcep-ifit/
Should this draft be adopted by the
Dear Dhruv Dhody,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
pce Session 1 (1:00 requested)
Wednesday, 27 July 2022, Session II 1330-1430
Room Name: Freedom E/F size: 150
Dear WG
I support adoption by PCE WG and would be willing to work on the draft.
I support IFIT PCE extension to carry the IFIT attributes for in-situ IOAM
on path telemetry. I do agree this would be very useful for operators.
I was looking for a framework draft for IFIT and this is what I
Hi Aijun,
Thanks for the support.
Regarding your question, I think we can clarify this point in the next version.
If a PCE instantiates a path on the PCC with an IFIT capability enabled, it is
supposed that there are at least two nodes (e.g. starting and ending node)
which support it. But if
Hi, All:
I support its adoption.
One questions to the authors:
Is it enough that only the headend support the defined iFIT capabilities?
What’s the procedures when the nodes on the LSP/SR path doesn’t support the
defined iFIT capabilities?
Aijun Wang
China Telecom
发件人: Dhruv
