Hi authors,
Thanks for continuing to work on this document.
Here are some minor comments. And one larger concern on Section 7.
Cheers,
Adrian
===
Your I-D has 6 front-page authors. The chairs can work with you on this, but 5
is the usual upper limit. Maybe, as this is an interop document, you
I think you may have missed it, Paul.
Try searching for TBD1 and TBD2 (both in section 2).
As to section 6.4 and the LSP-ERROR-CODE9, it is being deprecated so you might
not expect to find any further text.
Cheers,
Adrian
-Original Message-
From: Paul Wouters via Datatracker
Sent: 19 F
11 PM, Vishnu Pavan Beeram mailto:vishnupa...@gmail.com> > wrote:
Adrian,
Please see inline (prefixed [Beeram])
Regards,
-Pavan
On Fri, Feb 14, 2025 at 2:18 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Thanks again, Pavan.
[snip]
I read:
This color
Hi,
Sorry for being a bit late.
This document covers function we need to specify as the deployed PCE
scenarios get more complex.
I think the document is ready for publication. Just a few nits.
Best,
Adrian
= Nits =
1.
The
document does not state
I think "The
Thanks again, Pavan.
[snip]
I read:
This color attribute is used as a guiding
criterion for mapping services onto the TE tunnel
I took this to mean a guide for a classifier to know what traffic to place on
the TE tunnel. I.e., the second option.
[VPB] Yes, using color for mapping
k the semantics of FLOWSPEC to specify an attribute
of the TE tunnel? Maybe. We'll let the IESG decide if this draft needs to be
returned to the WG for discussing all possible alternative encoding mechanisms.
Regards,
-Pavan
On Wed, Feb 12, 2025 at 3:24 AM Adrian Farrel
Hi Pavan,
Thanks for the detailed response.
In line…
= Management Considerations =
The PCE working group produced recommendations to guide the inclusion of
manageability considerations sections in documents that it produces.
Those recommendations made a positive difference to the quality
I, too, was stimulated by the response on this point.
I am certainly not saying that the WG must change its approach here.
But, given that a mechanism already exists to carry information describing how
to associate traffic with an LSP, I thought that there should be some
discussion (not necessa
Thanks Marina,
Cutting down to just two points.
* 4.1 – I don’t so understand what is contradict
I originally wrote:
4.1 has:
The S-BFD parameters are only meant to be used for SR LSPs and with
PCEP peers which advertise SR capability.
This seems to contradict:
- The
Hi Haomian,
Thanks for prompting for comments and opinions.
I have read the latest version (-17) and have some thoughts. In
principle, this seems like a reasonable requirement and a neat solution.
It is a somewhat complicated use case that depends on the desire to
support various resto
Hi,
As draft-ietf-pce-pcep-ls approaches working group last call (it's
in the queue), I thought it would be good to look at this draft and see
whether it might be ready for adoption.
In some senses, PCEP-LS for optical is the under-lying driver for
PCEP-LS. That is, optical systems are less like
Hi,
I had a quick look at this draft as part of the adoption poll.
It is not unusual for a document being considered for adoption to need
additional work. This document certainly needs some attention. I have
included some issues and nits below, after my considerations with
respect of ad
teful-pce-vendor-12: (with COMMENT)
Hi Adrian,
On Wed, Nov 20, 2024 at 4:36 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi all,
I'm one of the authors of 7470.
I don't mind much about the outcome of this discussion, but the definition of
"Updates" *stil
Hi all,
I'm one of the authors of 7470.
I don't mind much about the outcome of this discussion, but the definition of
"Updates" *still* remains occluded ☹ [1]
7322 no longer provides a definition, and the old definition in 2223 was, I
think, confusing.
IMHO, "B updates A" means that to achiev
Hi Tingting,
Thanks for your presentation in today's meeting.
I wanted to expand on my comment about the use of a new UDP port number
specifically for PCEP over QUIC.
I am not a QUIC expert, and I suspect Dhruv isn't either, but we chatted
quickly and our understanding is the same. That is, the
of draft-ietf-pce-pcep-ls-01 in the context of
draft-bonica-gendispatch-exp
Hi Adrian,
Thanks for your review.
On Sun, Oct 20, 2024 at 6:42 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi,
I reviewed draft-ietf-pce-pcep-ls-01 through the lens of draft-bonica-
gendi
Hi,
I reviewed draft-ietf-pce-pcep-ls-01 through the lens of draft-bonica-
gendispatch-exp. Of course, that document is only a work in progress,
and even if it were published as an IETF consensus RFC, it would only be
guidance. But you may find this review helpful to smooth the passage of
your dr
Thanks, Haomian.
Lots of snipping, just leaving the conversations.
Cheers,
Adrian
> 1.
>
> However, I find the examples running through sections 1.2, 1.3, and 1.4 to
be quite
> unnecessary. There is a feeling of "trying too hard" to prove that there
are uses for
> the protocol extensions descri
p9fXsGHorZnnNAcN5fEnIYj3wg/2/>
smime.p7s
*
<https://mailarchive.ietf.org/arch/msg/pce/Ap9fXsGHorZnnNAcN5fEnIYj3wg/> [Pce]
WG Last Call for draft-ietf-pce-iana-update julien.meuric
*
<https://mailarchive.ietf.org/arch/msg/pce/UvP2g605Th1A2rbvVA1eSSh8aXI/> [P
Thanks Julien.
This is good and speedy progress (proof, if any were needed , that the IETF does not need to take multiple years to make simple changes).
As a co-author, I am content with the text and think it is ready to move forward.
Hi, I support this work.
I wonder whether it would be wise to merge with
draft-farrel-pce-experimental-errors so that we only have one IANA document in
the pipe.
Cheers,
Adrian
From: Andrew Stone (Nokia)
Sent: 31 July 2024 19:44
To: Ketan Talaulikar ; julien.meu...@orange.com
Does the working group want to pursue this?
If so: chairs, can we consider adoption?
If not: I can get a little peace by dropping the draft
Cheers,
Adrian
-Original Message-
From: internet-dra...@ietf.org
Sent: 03 July 2024 11:34
To: Adrian Farrel ; Haomian Zheng
Subject: New Version
Hi,
I'm continuing my campaign of reviewing PCE I-Ds that have been around
for a while. This one had a very long run as an individual I-D, saw an
implementation reported back in 2020, and was adopted in July last year.
It seems the work is pretty stable. Perhaps it's time to polish it and
move to
Hi,
As this document approaches being ready for working group last call, I
thought it might be helpful if I did a review.
Cheers,
Adrian
===
The document title could do with some clean-up.
- Remove the full stop
- Perhaps make it more straight-forward. For example, Procedures for
Communication
icate way to compute that metric in the name, maybe with just small
modification and replacing “Summed” with “Cumulative”).
Thanks,
Samuel
From: Adrian Farrel mailto:adr...@olddog.co.uk> >
Sent: Saturday, June 22, 2024 1:29 PM
To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com>
Although, I might be slightly wrong about the second metric because it is even
more than that.
Perhaps “Worst Leaf Summed Path Bandwidth”?
A
From: Adrian Farrel
Sent: 22 June 2024 12:13
To: 'Dhruv Dhody' ; 'pce@ietf.org'
Cc: 'pce-chairs' ; 'draft-ie
No objection, Dhruv, although it might be helpful to distinguish between the
Bandwidth metric advertised per link and the new PCEP metric type.
Perhaps call the new metrics “Summed Path Bandwidth” and “Summed P2PM Path
Bandwidth” because it is more descriptive?
Cheers,
Adrian
From: Dhru
Hi,
I support publication of this document, but I think there are some
issues that need to be resolved first. See below.
Cheers,
Adrian
===
Because of the (obvious) risk of confusion of what is meant by "color",
I tried to unpick the references. The important text is in the
Intr
Hi,
Thanks for this relatively simple document. I suspect it provides a function
that will be useful.
I do have some thoughts, however.
The Abstract says “This document describes a generic mechanism” but the
document actually seems to have nothing generic in it and requires a new TLV
an “Experimental
Use” range in the same registry.
So, I guess I retract my suggested changes.
Cheers,
Adrian
From: Adrian Farrel
Sent: 08 May 2024 09:07
To: 'Dhruv Dhody'
Cc: draft-ietf-pce-pcep...@ietf.org; pce@ietf.org
Subject: [Pce] Re: Changes for PCEP-LS IANA Cons
.
Thanks!
Dhruv
On Mon, May 6, 2024 at 3:04 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi,
Thanks for posting the adopted draft.
I think we need to make the following changes so catch all of the IANA
issues associated with being Experimental.
Cheers,
Adrian
===
Hi,
Thanks for posting the adopted draft.
I think we need to make the following changes so catch all of the IANA
issues associated with being Experimental.
Cheers,
Adrian
===
New section...
6.2. Experimental Error-Types and Error-Values
This experiment uses a single Experimental Use e
Thanks, Julien.
Once upon a time, I was quite skeptical about this idea, and unhappy to see it progress. But I have become used to the idea, and two things help me believe we should adopt this:
1. As an Experiment, this can be tried out and we
Hi PCE,
After some discussions with Dhruv about how and why we wrote RFC 8356,
Haomian and I have posted a new draft to allow Experimental error codes in
PCEP.
In summary, 8356 created space for Experimental PCEP messages, objects,
TLVs.
The assumption (see Appendix A) was that you could do anyth
Hi,
I've read the new version of this draft.
I think it is ready for publication, but you have used smart quotes for
the apostrophes in the Abstract and Introduction.
Thanks for all the work.
Adrian
-Original Message-
From: Pce On Behalf Of julien.meu...@orange.com
Sent: 09 November 2
Thanks Ran,
I’ll try to get to that soon.
Adrian
From: chen@zte.com.cn
Sent: 01 October 2023 18:42
To: d...@dhruvdhody.com; adr...@olddog.co.uk
Cc: pce@ietf.org; draft-chen-pce-b...@ietf.org
Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11
Hi Dhruv，
Thanks for remindi
Hi,
I have no objection to the working group taking on this draft although
I suspect that the community of interest is quite small, so there is
some concern about proper review and WG consensus. Hopefully this
adoption poll will secure a few promises of future review.
A few editorial poi
In the past, I would have agreed with Tom on this.
But we are routinely seeing a pause of more than 200 days between a WG issuing a Publication Request and the AD starting their review (which leads to updates and discussion before IETF last call). IANA don't do the
Hey Julian.
Yes, let's move this little draft forward quickly and ensure PCEP can be as
secure as possible.
A
-Original Message-
From: Pce On Behalf Of julien.meu...@orange.com
Sent: 27 March 2023 10:49
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-dhody-pce-pceps-tls13-02
De
> Many thanks for your comments, I have accepted most of the comments
> from you, and would like to discuss with you about the rest. Please see my
> reply inline.
Great. Thanks, Cheng. Continuing the discussion in line.
Snipped all of the resolved stuff.
> Because we have a lots of comments. It
Hi again, Dhruv.
Still not pushing this idea, but still trying to make sure it is correctly
understood….
Of course an (unpopular) option would be to tell the PCE WG that it is not
acceptable to use the RSVP-TE registries in this way, and let them know that
if they want to specify paths for
Looks like I was somewhat right with “unpopular” 😊
Of course an (unpopular) option would be to tell the PCE WG that it is not
acceptable to use the RSVP-TE registries in this way, and let them know that
if they want to specify paths for other uses they should use a new PCEP ERO
and RRO Object-T
Hi,
Here is my WG last call review of this document. Thanks to the authors
for all of the work that has gone in.
[A note for the chairs: Was this last call shared with SPRING?]
Cheers,
Adrian
===
Abstract
The Source Packet Routing in Networking (SPRING) architecture
In fact, although RFCs
Hi,
You may recall that, back in the early days, the plan for PCEP was that it
was used to determine the paths that were to be signalled in MPLS-TE and to
report on those paths.
To that end, the ERO and RRO in PCEP messages follow the same construction
as those used in RSVP-TE. That is, they are
Hi,
Tl;dr I support the adoption of this draft.
As a co-author of RFC 8283, I take an interest in this work and the
wider applicability of PCECC. I've also been interested in how SID
allocation is coordinated, and this seems like a reasonable solution.
Given that we have procedures and protocol
As promised, I’m commenting into this thread as well. Picking Dhruv’s email
from the thread because it best captures my feelings on the work.
As I noted in the review I just posted, there seem to be a few (small but
important) clarifications and changes to the previous specs that need to be
Hi,
This is another fly-by review as I just saw the new revision of the
draft pop up. I think it is important and helpful that implementers of
IETF protocol work get together to document their experiences with the
technology, so thanks to the authors for their work.
However, I am concerned when
Wfm, thnx
-Original Message-
From: Russ Housley
Sent: 14 October 2022 14:58
To: Adrian Farrel
Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org
Subject: Re: Thinking about draft-dhody-pce-pceps-tls13
Maybe the phrase should be: PCEP implementations that support TLS 1.3 MUST
specification"
makes all the concerns go away.
Cheers,
Adrian
-Original Message-
From: Russ Housley
Sent: 14 October 2022 13:46
To: Adrian Farrel
Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org
Subject: Re: Thinking about draft-dhody-pce-pceps-tls13
Adrian:
TLS 1.2 doe
Hi,
Thanks for kicking off work to get PCEP able to work with TLS1.3.
This is important.
However... :-)
I think it would be helpful to clarify that statements about what
implementations must or must not do (etc.) should be scoped as
"implementations of this document." That is, you are not const
Gredler
; JP Vasseur (jvasseur) ;
meral.shirazip...@polymtl.ca; Adrian Farrel
Subject: RE: [Lsr] Lars Eggert's Discuss on
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
John -
So you are suggesting that Section 4 of the draft be modified to say:
"This intro
Adrian
-Original Message-
From: John Scudder
Sent: 04 October 2022 18:29
To: Lars Eggert
Cc: The IESG ;
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org;
lsr ; Acee Lindem ; pce@ietf.org; Hannes Gredler
; Les Ginsberg (ginsberg) ;
jvass...@cisco.com; meral.
Hi,
I read through this draft as part of the adoption poll.
I found it quite hard to work out from the Abstract what the purpose of
the document is. The Introduction is a little more informative, but also
quite hard work.
It turns out, when you read the document, that two things are b
Thanks Haomian,
Looking good.
Cut down to just a few open points.
Best,
Adrian
4. (for VIRTUAL-NETWORK-TLV)
Length: Variable Length
Length of what and in what units?
Just the Virtual Network Name or the whole TLV?
Probably in octets.
What is the maximum allowed value?
PCEP and list out how they are used. Then we can have a starting point for a
conversation.
Cheers,
Adrian
From: Dhruv Dhody
Sent: 17 March 2022 05:20
To: Adrian Farrel
Cc: pce@ietf.org; draft-ietf-pce-vn-associat...@ietf.org; pce-chairs
Subject: ASCII in PCEP (WAS - Re: [Pce] WGLC
Hi,
Here is my review of draft-ietf-pce-vn-association-05 as part of the WG
last call.
I think the document is technically ready to proceed, but it needs quite
a bit of work to polish the text. After the number of edits I am
proposing I feel like I have rewritten the document!
My co
Hi authors,
I really appreciate the work done through interop to better understand protocol
specs and revise the protocol. I hope that you are not all talking yourselves
into an interop mode that changes the specs because that seems to interoperate,
rather than fixing implementations to conform
Hi,
It's been a journey for this draft! July 2012 :-)
Glad that we are finally in a place to last call it, and excellent to
know there is an implementation.
Here is my review in support of the last call. You'll see that my minor
points are essentially editorial (i.e., not asking to chang
Hi Julien,
I'm sorry, I missed the adoption poll (although I saw and responded to Hari's
email about IPR).
This document is the right way to start documenting how to do a PCEP flowspec
for L2 flow identification. Indeed, this mechanism was part of
draft-ietf-pce-pcep-flowspec but got pulled ou
Hi Hari,
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
Cheers,
Adrian
From: Hariharan Ananthakrishnan
Sent: 16 December 2021 18:24
To: Farrel Adrian ; Dhruv Dhody ;
lizhen...@huawei.com
Cc: pce@ietf.org
Subject: IPR Poll
clear.
Many Thanks!
Gyan
On Wed, Aug 25, 2021 at 10:30 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Yes, thanks, Gyan.
I think you have captured it all, although some of the behaviours are “hidden”
in assumptions in the text.
That is:
* A PCEP speaker that
, 2021 at 2:40 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi Gyan,
I am very much in favour of positioning this work as Experimental.
It is important (as with all IETF Experiments) to capture:
- What stops this extension “escaping" in the Internet?
-
loyed equipment?
- How will you judge the success or failure of the experiment, and
when?
- What follow-up to the experiment do you propose?
Best,
Adrian
From: Gyan Mishra
Sent: 05 July 2021 07:43
To: Adrian Farrel ; Dhruv Dhody ;
draft-dhodylee-pce-pcep...@ietf.org
Hi Cheng!
This is good progress, thanks.
I have cut down to the points that are still open.
Nothing we need to fight about 😊
Best,
Adrian
>> == Questions / Issues ==
>>
>> 3.
>>
>> o BT = 0: The binding value is an MPLS label carried in the format
>> specified in [RFC5462] where only t
Hi Julien, WG, authors.
Code point allocation: Is the request for all of the code points in the
document? What about the not-yet-allocated code point from
[I-D.ietf-pce-pcep-extension-for-pce-controller]. This spec can't be
implemented without it.
WG last call: I have a few questions/issues/nits
ding-label-sid-06#section-11.2
Note it's also reused in
https://tools.ietf.org/html/draft-ietf-pce-sr-path-segment-03#section-4.2
Have a nice week-end,
Julien
On 18/02/2021 16:57, Adrian Farrel wrote:
> Thanks to the authors for cleaning this up a lot since last time.
>
> I don't
Thanks to the authors for cleaning this up a lot since last time.
I don't object to adoption. Would be nice to have evidence of someone
needing a bit now, but by the time this becomes an RFC it is reasonably
possible.
Adrian
-Original Message-
From: Pce On Behalf Of Dhruv Dhody
Sent: 01
Hi,
I've reviewed this draft and I think it is ready for adoption because
the functionality (i.e., stitching segments without inter-domain
signaling which means that path-key cannot be used) is valuable.
There are a number of editorial comments below. I think they do not
need to be addressed bef
Hi,
As a contributor, I am not aware of any IPR applicable to this draft that
should be disclosed in accordance with IETF IPR rules.
Thanks,
Adrian
From: Pce On Behalf Of Hariharan Ananthakrishnan
Sent: 26 November 2020 22:58
To: lizhen...@huawei.com; pengshup...@huawei.com; Mahend N
Hello all,
I was a contributor to some of the earlier versions of this document and am
listed as such (although I don't think I work for Juniper any more).
I think the document is in a good enough state for adoption.
Post-adoption there are some things that could benefit from work...
- I worry
Hi again Gyan,
I think we’re narrowing down and getting somewhat esoteric for the mailing
lists we’re spamming.
> Similarly other use cases such as with TEAS TS-Transport slice and being able
> to provision TS and capturing the TS Enhanced VPN RT & resource information
> and leveraging BGP-LS
Hi Gyan,
Sorry, I missed this (got caught on a filter cos it was a bit spammed to a lot
of lists :-).
> I have noticed that after reviewing many drafts across many WGs it seems in
> the
> industry that the lines seem to be blurred between a PCE controller, ODL or
> Openflow SDN Controll
This draft is a work item of the Path Computation Element WG of the IETF.
Title : PCEP Extension for Flow Specification
Authors : Dhruv Dhody
Adrian Farrel
Zhenbin Li
Filename: draft-ietf-pce-
Just to repeat what I said when Shuping proposed the changes...
This revision addresses all the points in my review.
Cheers,
Adrian
-Original Message-
From: Pce On Behalf Of internet-dra...@ietf.org
Sent: 02 September 2020 03:37
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-
ssage-
From: Alvaro Retana
Sent: 26 August 2020 23:20
To: adr...@olddog.co.uk; The IESG
Cc: pce-cha...@ietf.org; pce@ietf.org; Julien Meuric
; draft-ietf-pce-pcep-flows...@ietf.org
Subject: RE: Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with
DISCUSS)
On August 26, 2020 a
yet the scissors are sharp and they enjoy running.
You paragraph of suggestions of pointers of how/when to do AND and OR is a
reasonable starting point. But surely it is something that belongs in
5575bis?
Cheers,
Adrian
On Wed, Aug 26, 2020 at 09:51:52PM +0100, Adrian Farrel wrote:
> Hi Ben,
&
c'
Subject: RE: Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10:
(with COMMENT)
Hi Adrian!
> -Original Message-
> From: Adrian Farrel
> Sent: Wednesday, August 26, 2020 5:09 PM
> To: Roman Danyliw ; 'The IESG'
> Cc: draft-ietf-pce-pcep-fl
Hi Alvaro,
Responding to your Discuss separately from your Comment to get you an answer
before the telechat.
> DISCUSS:
>
> §8.7: "it is possible that Flow Specifications will be distributed by BGP as
> well as by PCEP as described in this document...implementations MAY provide a
> configuration
Hi Roman,
> COMMENT:
>
> ** Section 12. To refine what Ben Kaduk noted about the applicability of
> [RFC6952], Section 2.5 seems to apply for me.
Yes, that it the relevant section, and I've added an explicit section pointer.
> ** Section 12. Per “Therefore, implementations or deployments conce
Hi Ben,
Thanks for the review.
A lot of very helpful comments and discussions.
All answers in line.
I have a working copy with the edits (hint to co-authors: *I* have the working
copy :-)
Best,
Adrian
> DISCUSS:
>
> As with the others, I also found this document to be quite easy to
> read and w
Thanks again Erik,
Processing the details now...
> [ section 2 ]
>
> * "a flag is provided to indicate that the sender of a PCEP message
> that includes a Flow Specification is intended to be installed as
> a Longest Prefix Match route, or..."
>
> This didn't scan too well for me. It seems th
Thanks, Martin.
> Sec 5. Specify the error if more than 1 TLV of any type is present.
Yes. Both TLVs earn the text...
If
more than one instance of this TLV is present, the first MUST be
processed and subsequence instances MUST be ignored.
> Sec 7. The text is incomplete for the
Nice collection of nits, Erik. Thanks.
Will attend to them when the next version comes out.
Best,
Adrian
-Original Message-
From: Erik Kline via Datatracker
Sent: 23 August 2020 02:28
To: The IESG
Cc: draft-ietf-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org; pce@ietf.org;
Julien Me
Thanks Eric,
Yes, that's a good catch. Embarrassed that is sneaked through.
I now have
The Value field MUST be set to 0 and MUST be ignored on receipt.
in my working copy.
Best,
Adrian
-Original Message-
From: Éric Vyncke via Datatracker
Sent: 18 August 2020 11:14
To: The IESG
Cc:
n-for-pce-controller-07.txt
We have also updated Chao Zhou's email address in the draft.
Thank you!
Best regards,
Shuping
> -Original Message-----
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, August 17, 2020 12:15 AM
> To: julien.meu...@orange.com; pce
Looks like you need to update Chao Zhou's email address in the draft.
Adrian
-Original Message-
From: Pce On Behalf Of Adrian Farrel
Sent: 16 August 2020 17:15
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
Subject: Re: [Pce
Hi Julien, WG, authors,
I'm listed as one of the eight Contributors to this document, although
my affiliation should read "Old Dog Consulting".
I was a co-author of RFC 8283, so I am generally glad to see protocol
work addressing this space.
This document is almost ready to progress, but there a
Thanks for taking time to so the review, Roni.
Best,
Adrian
-Original Message-
From: Roni Even via Datatracker
Sent: 03 July 2020 08:08
To: gen-...@ietf.org
Cc: pce@ietf.org; last-c...@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org
Subject: Genart last call review of draft-ietf-pce-
avan Beeram
Sent: 13 January 2020 12:23
To: Adrian Farrel
Cc: pce@ietf.org; draft-ietf-pce-pcep-flows...@ietf.org
Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec
Adrian, Hi!
Please see inline..
Regards,
-Pavan
On Fri, Jan 10, 2020 at 10:32 AM Adrian Farrel wrote:
&
Thanks Rakesh,
It seems to me that associating an SR path in one direction with an RSVP-TE
path in the other direction is *possible* but seems unlikely in the extreme. I
would not want to take an action that made it impossible to add this feature
should someone come up with a pressing desire
.
Title : Updated Rules for Processing Stateful PCE Request
Parameters Flags
Author : Adrian Farrel
Filename: draft-ietf-pce-stateful-flags-01.txt
Pages : 7
Date: 2020-01-23
Abstract:
Extensions to the Path
>> Every review comment deserves a response.
>
> You're too kind!
Never knowingly 😉
> Both proposed changes look good to me :)
Great, thanks. They are in the buffer.
A
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Hi again Alvaro
A separate thread for your Comments (since your Discuss was so juicy!)
> (1) Compatibility
>
> The compatibility issue described at the end of §4 could result in all types
> of
> unforeseen errors or more serious issues; even considering just the one flag
> defined in rfc8281: th
Hello Alvaro,
Thanks for this Discuss. I think you found a hole in
draft-ietf-pce-lsp-control-request. It doesn't look like a big hole because if
you tried to apply both the C and the R flag, presumably the R flag would get
executed making the C flag irrelevant. But I agree that the clarity of
> Thanks for this clear and well-written document! I just have a couple
> of editorial comments that probably don't even need a response.
Thanks for reading, Ben.
Every review comment deserves a response.
> Section 4
>
> There will remain an issue with compatibility between implementations
>
Hey Julien, WG,
I have reviewed draft-li-pce-sr-bidir-path as part of the adoption poll
and I have a few comments below.
Overall, this seems like a simple combination of two existing functions:
- associated bidirectional
- SR
So it should be straightforward and the function is clearly needed, and
it wants to describe what traffic to associate
with a path.
Like you, I would like to hear more from the working group.
Cheers,
Adrian
From: Vishnu Pavan Beeram
Sent: 10 January 2020 05:45
To: Adrian Farrel
Cc: pce@ietf.org; draft-ietf-pce-pcep-flows...@ietf.org
Subject: Re: [Pce] A
Hi WG,
I received a couple of private emails about draft-ietf-pce-pcep-flowspec.
Since they were private, I will try to be circumspect about who they were
from.
The sender asked to have a flag attached to a flow specification that
indicates that it can be installed as a static route and thus not
Hi Julien,
Long ago you sent your review. Comments in line.
At the same time, we see that IDR has basically completed work on
draft-ietf-idr-rfc5575bis and we think we should update this document to use
that as a reference instead of RFC 5575 and RFC 7674.
Finally, someone contacted us private
Hi authors,
Just doing the shepherd write-up after working group last call and I have a
nit in section 10.3
You ask for a new registry of bits, but you don't tell IANA the size of the
registry.
I think, to be consistent with (e.g.)
https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-ca
1 - 100 of 499 matches
Mail list logo
