Re: [Pce] Opsdir last call review of draft-ietf-pce-lsp-setup-type-08

[Benjamin Kaduk]

On Fri, Mar 02, 2018 at 05:15:05PM +, Jonathan Hardwick wrote:
> 
> -Original Message-
> From: Dan Romascanu [mailto:droma...@gmail.com] 
> Sent: 28 February 2018 15:23
> To: ops-...@ietf.org
> Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-lsp-setup-type@ietf.org; 
> droma...@gmail.com
> Subject: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08
> 
> 2. How are the new TLVs going to be deployed and managed? Does an operator 
> have the option of selecting one LSP setup method or the other? How and what 
> are the criteria of selections?
> 
> 3. There is no discussion about initial setup and configuration. Are there 
> any initial configuration parameters? If yes, how are they set up?
> 
> 4. Are there any backwards compatibility and migration path issues operators 
> should be aware about?
> 
> 5. What is the expected impact on network operation?
> 
> 6. How is correct operation visible to the operators? Are there any fault 
> conditions that need to be reported to operators?
> 
> 7. Are there any existing management interfaces (e.g. YANG models) that need 
> to be defined or extended?
> 
> Jon> I think the above points 2..7 are really good questions to be asking 
> about each new path setup type that we introduce.  In a draft that is 
> agnostic of path setup type, I don't really know how to answer them.  For 
> example, I would expect draft-ietf-pce-segment-routing to answer these 
> questions in the context of configuring and enabling PCEP for segment 
> routing.  Do you think that there is something we can usefully say about 
> working with multiple path setup types in general?

One thing you could do is include that list of questions in the
document as things that authors of new path setup types should think
about.

-Benjamin

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] 答复: WG adoption poll for draft-li-pce-pcep-flowspec-03

[Cyril Margaria]

Yes/Support .




On 23 February 2018 at 00:51, Aijun Wang  wrote:

> Yes/Support
>
>
>
> *发件人:* Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> *发送时间:* 2018年2月20日 21:34
> *收件人:* pce@ietf.org
> *抄送:* draft-li-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org
> *主题:* [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03
>
>
>
> Dear PCE WG
>
>
>
> This is the start of a two week poll on making
> draft-li-pce-pcep-flowspec-03 a PCE working group document.
>
> https://datatracker.ietf.org/doc/draft-li-pce-pcep-flowspec/
>
>
>
> Please review the draft and send an email to the list indicating
> “yes/support” or “no/do not support”.  If indicating no, please state your
> reasons.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
>
>
> The poll ends on Tuesday, March 6.
>
>
>
> Many thanks,
>
>
>
> Jon and Julien
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Genart last call review of draft-ietf-pce-lsp-setup-type-08

[Jonathan Hardwick]

Hi Roni

Many thanks for the review.  You are right, in this case we meant "IETF 
Review".  I will update the document.

Cheers
Jon

-Original Message-
From: Roni Even [mailto:ron.even@gmail.com] 
Sent: 26 February 2018 14:55
To: gen-...@ietf.org
Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-lsp-setup-type@ietf.org
Subject: Genart last call review of draft-ietf-pce-lsp-setup-type-08

Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-pce-lsp-setup-type-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-04-05

Summary:
The document is almost ready for publication as standard track RFC Major issues:

Minor issues:
1. in section 7.2 "The allocation policy for this new registry  should be by 
IETF Consensus" why not use one of RFC8126 well known policies?

Nits/editorial comments:


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Opsdir last call review of draft-ietf-pce-lsp-setup-type-08

[Jonathan Hardwick]

Hi Dan

Many thanks for the review.  Please see my replies below - look for "Jon>".

Best regards
Jon


-Original Message-
From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: 28 February 2018 15:23
To: ops-...@ietf.org
Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-lsp-setup-type@ietf.org; 
droma...@gmail.com
Subject: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08

Reviewer: Dan Romascanu
Review result: Has Issues

I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews 
a great part of the IETF documents being processed by the IESG for the OPS ADs.
Please treat with these comments as with all other IETF LC comments. Please 
wait for direction from your document shepherd or AD before posting a new 
version of the draft.

This document is an extension of PCEP to allow for other LSP setup methods than 
RSVP-TE to be used. For this purpose it defines two new TLVs and details their 
operation.

This is an extension of an existing protocol. An RFC 5706 review applies.

While the document seems to be focused to developers and implementers of PCEP, 
it is not clear what is the impact from an operational point of view and there 
are no considerations related to manageability. Maybe these are detailed in 
other documents - in this case a reference would be useful.

Jon> The context of this draft is that it generalizes PCEP so that the protocol 
is not dependent solely on using RSVP-TE as a method for setting up paths.  The 
document performs this generalization, positioning RSVP-TE as one possible 
method of path setup, but it stops short of defining any other path setup 
methods.  Since no new path setup methods are being introduced, the 
manageability and operational considerations do not really change.  We have 
simply generalized a part of PCEP to allow other path setup methods (and their 
manageability considerations) to be defined elsewhere.


Here are a few issues. For a complete list of questions, see Annex A in RFC 
5706.

1. Why were these extensions needed? Do they improve efficiency? Are there 
classes of devices that do not support RSVP-TE and need the new methods?

Jon> This is a pre-requisite step to allow PCEP to be used in networks that use 
segment routing to define paths.  Segment routing (SR) is a distinct path setup 
method from RSVP-TE.  It is possible that SR devices might not support RSVP-TE. 
 The WG took the decision to write one draft to generalize PCEP (this draft) 
and then to write a separate draft to explain how this generalization is 
applied to segment routing (draft-ietf-pce-segment-routing).  The latter draft 
is post-WGLC in the PCE WG and should be catching up with 
draft-ietf-pce-lsp-setup-type shortly.  Why did we not combine 
draft-ietf-pce-lsp-setup-type and draft-ietf-pce-segment-routing?  Suppose we 
invent a third path setup type in future.  It is clearer for implementers that 
they only need to implement the procedures of draft-ietf-pce-lsp-setup-type in 
order to prepare the ground for this third path setup type - having one 
combined draft incorporating SR as well would make this harder.


2. How are the new TLVs going to be deployed and managed? Does an operator have 
the option of selecting one LSP setup method or the other? How and what are the 
criteria of selections?

3. There is no discussion about initial setup and configuration. Are there any 
initial configuration parameters? If yes, how are they set up?

4. Are there any backwards compatibility and migration path issues operators 
should be aware about?

5. What is the expected impact on network operation?

6. How is correct operation visible to the operators? Are there any fault 
conditions that need to be reported to operators?

7. Are there any existing management interfaces (e.g. YANG models) that need to 
be defined or extended?

Jon> I think the above points 2..7 are really good questions to be asking about 
each new path setup type that we introduce.  In a draft that is agnostic of 
path setup type, I don't really know how to answer them.  For example, I would 
expect draft-ietf-pce-segment-routing to answer these questions in the context 
of configuring and enabling PCEP for segment routing.  Do you think that there 
is something we can usefully say about working with multiple path setup types 
in general?

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce