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
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
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
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
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
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
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
> 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
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
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
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
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
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 does not have
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
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 introdu
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.shirazip..
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
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
in
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
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
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
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
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
-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 object to adopti
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:
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
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
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
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
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
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]
: 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 at 5:25:20 PM, Adrian
issors 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,
>
> Thank
: 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-flows...@ietf.org; pce-cha...@ietf.or
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
>
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
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
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
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
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
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
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] 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
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
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
.
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:
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,
if 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
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
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.)
Hi Ben,
In the absence of a response from the authors this last month, I'm jumping
in because I want to see this published.
Authors/shepherd/chairs/AD: attached is an xml file that makes these
changes. I can't post it cos I'm not an author.
Cheers,
Adrian
===
> Thank you for addressing my
Hi,
I wouldn't object to any solution.
- What Dhruv suggests
- Just 32 bits and define a new TLV if more bits are ever needed
Best,
Adrian
-Original Message-
From: Dhruv Dhody
Sent: 02 December 2019 05:28
To: xiong.q...@zte.com.cn
Cc: Farrel Adrian ; Stone, Andrew (Nokia - CA/Ottawa)
Hi Quan,
Thanks for picking up this work. You are right that we need a solution.
A couple of points about your draft…
I don’t think it is necessary or advisable to repeat the format of the existing
PLSP-ID object, or to list the currently-assigned bits and meanings. Doing so
creates
Thanks, Julien.
We have received a private communication from someone about the same section so
the authors are going to take a little time to try to work over this section.
We'll see whether our changes make enough difference to warrant re-polling that
section with the WG.
Cheers,
Adrian
--
item of the Path Computation Element WG of the IETF.
>
> Title : Updated Rules for Processing Stateful PCE
Request Parameters Flags
> Author : Adrian Farrel
> Filename: draft-ietf-pce-stateful-flags-00.txt
> Pages : 6
>
Hello Deborah,
I wonder whether something has changed in the IETF process that I'm not aware
of. That is possible.
> Adrian, I'm also a bit confused on the intention of the draft. While
> the tools are not error checking a draft with intended status of PS
> against a title indicating an
To: Adrian Farrel ; Dhruv Dhody ;
Zhenbin Li
Subject: New Version Notification for draft-ietf-pce-pcep-flowspec-06.txt
A new version of I-D, draft-ietf-pce-pcep-flowspec-06.txt
has been successfully submitted by Adrian Farrel and posted to the
IETF repository.
Name: draft-ietf-pce-pcep
Hi Mike,
Thanks for taking the time to read this.
> Great job on the easy to understand draft. I probably
> don't want to know the history of why this is an individual
> draft but I am curious. I'll ask Adrian over a drink sometime.
Not rejecting the idea of a drink, but just sharing with the
Hi Acee,
Thanks for the review and the kind words.
I believe this document is in WG last call at the moment, so this is not quite
so early as an “Early Review” might normally be.
> I have a question and a few suggestions:
>
>1. For the multicast flow filter TLVs, is there some reason why
>
Hi Julien,
Probably no surprise: as an author, I support this document going forward.
I just did a quick re-read of the draft and don't see any issues beyond the
fact that Section 11 refers to the -04 version.
Thanks,
Adrian
-Original Message-
From: Pce On Behalf Of
Hi Hari,
I am not aware of any IPR applicable to this draft that should be disclosed in
accordance with IETF IPR rules.
Thanks,
Adrian
From: Hariharan Ananthakrishnan
Sent: 14 October 2019 18:00
To: Dhruv Dhody ; Farrel Adrian ;
lizhen...@huawei.com
Cc: pce@ietf.org
Subject: IPR
Hi,
Now I'm no longer one of the PCE chairs, I have a little more time for
reviewing works in progress.
This document popped up as a candidate because it has been around for a
long time and is now on its eleventh version. (It's also not too long,
which makes it attractive.)
I hope these
: Adrian Farrel
Filename: draft-farrel-pce-stateful-flags-02.txt
Pages : 6
Date: 2019-09-23
Abstract:
Extensions to the Path Computation Element communications Protocol
(PCEP) to support stateful Path Computation Elements (PCEs
Hi,
I’m willing to be guided here.
I don’t think the new draft makes any changes to how a code point seen in in
the wild should be interpreted.
And the “updates” relationship will be in place.
But if people think it is valuable we could have…
IANA maintains a registry called the “Path
Yes, that's a reasonable request.
Should send a Notification.
If congested or would only serve to increase overload, May choose to not send a
Notification.
Not sending a Notification could result in foo
A PCC experiencing foo should to bar.
Note that when a PCE serves very many PCCs, congestion
Top post, historic view.
IIRC the reason for not requiring a Notification in the case of overload was
that the process of sending a Notification might contribute to the overload.
And, furthermore, that there might be an attack that leverages the need to send
a Notification to perpetuate the
Hi Hari,
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
Thanks,
Adrian
From: Hariharan Ananthakrishnan
Sent: 06 September 2019 15:41
To: Farrel Adrian
Cc: pce@ietf.org
Subject: IPR Poll on
Dhruv, WG,
You'll be unsurprised to know I think this document is ready to proceed.
I've even read it.
Adrian
-Original Message-
From: Dhruv Dhody
Sent: 30 August 2019 19:14
To: pce@ietf.org
Cc: pce-chairs
Subject: WG LC for draft-farrel-pce-stateful-flags-01
Hi WG,
This email
You had me at the mention of beer.
Actually, that would be a useful conversation both in a PCE context and in a
wider SDN context. (Always said that the SDN architecture was missing a bit of
security work).
I'd also love us to have some clarity about TCP-AO. It's like we were all told
we must
Thanks to all who responded to this poll.
The result was not overwhelming, but the chairs think that there is just
about enough support to move forward.
Authors, please post the draft as draft-ietf-pce-vn-association-00 with no
changes except for the name, and be sure to set the "replaces"
Hi Qin,
I didn't see any response to this email, so I thought I should chip in with
some (old, old, old) memories and context.
tl;dr I am generally supportive of this work, but I think a little
fine-tuning is needed.
If I recall correctly, the situation when 5088 and 5089 were produced was
that
13:23
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-farrel-pce-stateful-flags-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Updated Rules for Processing Stateful PCE Request
Parameters Flags
Author : Adrian
Adrian Farrel
Zhenbin Li
Filename: draft-ietf-pce-pcep-flowspec-05.txt
Pages : 32
Date: 2019-08-15
Abstract:
The Path Computation Element (PCE) is a functional component capable
of selecting
.
Especially happy to hear form those who have read the draft, and those who
plan to help with reviews and implementations.
Thanks,
Adrian (still trying to step down!)
-Original Message-
From: Pce On Behalf Of Adrian Farrel
Sent: 14 July 2019 14:00
To: pce@ietf.org
Cc: draft-leedhody-pce-vn
hruv Dhody
Adrian Farrel
Zhenbin Li
Filename: draft-ietf-pce-pcep-flowspec-04.txt
Pages : 32
Date: 2019-08-07
Abstract:
The Path Computation Element (PCE) is a functional component capable
of selecting
***
-Original Message-
From: Pce On Behalf Of Adrian Farrel
Sent: 24 June 2019 08:04
To: pce@ietf.org
Subject: [Pce] New draft draft-farrel-pce-stateful-flags-00.txt
Hi,
While reviewing draft-ietf-pce-lsp-control-request I noticed that RFC 8231
is missing clarity about how to handle the Flags field
Hi WG,
He authors of draft-leedhody-pce-vn-association have been asking for
adoption and...
- the base PCEP association extensions seem to be stable and advancing
- I did an early review and the authors span a new version
So, this starts an adoption poll for the draft. Because IETF-105 is
Thanks for the catch, Mirja.
But authors, please fix as "the association types are defined"
Thanks,
Adrian
-Original Message-
From: Mirja Kühlewind via Datatracker
Sent: 09 July 2019 15:19
To: The IESG
Cc: draft-ietf-pce-association-gr...@ietf.org; Julien Meuric
;
Message-
From: internet-dra...@ietf.org
Sent: 24 June 2019 07:53
To: Adrian Farrel
Subject: New Version Notification for draft-farrel-pce-stateful-flags-00.txt
A new version of I-D, draft-farrel-pce-stateful-flags-00.txt
has been successfully submitted by Adrian Farrel and posted to the
IETF
Hi,
Since you indicated that you thought your draft was ready for adoption
by the working group, I have done a quick review. I realise that this
is work in progress and does not need to be perfect or even complete
at this stage, so I have tried to just pick out some points to tidy up
the document
Thanks Dan.
Deborah, good to go.
Adrian
-Original Message-
From: Pce On Behalf Of dan...@olddog.co.uk
Sent: 17 June 2019 23:03
To: pce@ietf.org
Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-hpce-10.txt
Hi All,
This revision of the I-D adjusts the number of document authors,
Hi,
Picking up on Dhruv's request, I did a quick review as co-chair. It's
after the end of WG last call, but life is full of little
disappointments.
Enjoy!
Adrian
===
Please reduce to five or fewer authors on the front page or provide the
shepherd with a good reason why not.
---
Please
Adrian Farrel has requested publication of draft-ietf-pce-stateful-hpce-09 as
Informational on behalf of the PCE working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/
___
Pce mailing list
Thanks, Dan,
I'm checking the diffs and then I'll do the shepherd write-up and move the
document along.
Best,
Adrian
-Original Message-
From: Daniel King On Behalf Of dan...@olddog.co.uk
Sent: 10 June 2019 13:21
To: adr...@olddog.co.uk
Cc: pce@ietf.org
Subject: RE: [Pce] Review of
Adrian Farrel has requested publication of
draft-ietf-pce-stateful-pce-auto-bandwidth-09 as Proposed Standard on behalf of
the PCE working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth
All,
Obviously we have cut some slack for the documents that are further
advanced.
But a number of you have asked that your drafts be considered for WG last
call, and a few are in the queue (see the lists on the wiki at
https://trac.ietf.org/trac/pce/). If you are hoping that your document will
1 - 100 of 323 matches
Mail list logo
