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

[Dan Romascanu]

Hi Jon,

This looks very good and addresses my concerns. Thanks for the dialog and
for the responsiveness.

Regards,

Dan


On Mon, Mar 12, 2018 at 6:44 PM, Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> Hi Dan
>
>
>
> I have written the following text to address the general question of
> manageability of different LSP Setup types and plan to include it in the
> next revision of this draft.  Please let me know if you have any comments.
>
>
>
> NEW (insert before “Security Considerations” section)
>
>
>
> 6. Manageability Considerations
>
>
>
> This document generalises PCEP to allow path setup methods other than
> RSVP-TE to be used by the network.  It is possible that, in a given
> network, multiple path setup methods will be used.  It is also possible
> that not all devices will support the same set of path setup methods.
> Managing networks that combine multiple path setup methods may therefore
> raise some challenges from a configuration and observability point of view.
>
>
>
> Each document that introduces a new path setup type to PCEP must include a
> manageability section.  The manageability section must explain how
> operators can manage PCEP with the new path setup type.  It must address
> the following questions, which are generally applicable when working with
> multiple path setup types in PCEP.
>
>- What are the criteria for when devices will use the new path setup
>type in PCEP, and how can the operator control this?
>- How can the network be migrated to the new path setup type, and are
>there any backwards compatibility issues that operators need to be aware 
> of?
>- Are paths set up using the new path setup type intended to coexist
>with other paths over the long term and, if so, how is this situation
>managed with PCEP?
>- How can operators verify the correct operation of PCEP in the
>network with respect to the new path setup type?  Which fault conditions
>must be reported to the operators?
>- Are there any existing management interfaces (such as YANG models)
>that must be extended to model the operation of PCEP in the network with
>respect to the new path setup type?
>
>
>
> See [RFC 6123] for further guidance on how to write manageability sections
> in PCEP standards-track documents.
>
>
>
> END NEW
>
>
>
> + [RFC 6123] is added as an informative reference.
>
>
>
> Many thanks
>
> Jon
>
>
>
>
>
>
>
> *From:* Dan Romascanu [mailto:droma...@gmail.com]
> *Sent:* 03 March 2018 10:57
> *To:* Jonathan Hardwick 
> *Cc:* ops-...@ietf.org; pce@ietf.org; i...@ietf.org;
> draft-ietf-pce-lsp-setup-type@ietf.org
> *Subject:* Re: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08
>
>
>
>
>
>
>
> On Fri, Mar 2, 2018 at 7:15 PM, Jonathan Hardwick <
> jonathan.hardw...@metaswitch.com> wrote:
>
> 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.
> a...@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 

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

[Jonathan Hardwick]

Hi Dan

I have written the following text to address the general question of 
manageability of different LSP Setup types and plan to include it in the next 
revision of this draft.  Please let me know if you have any comments.

NEW (insert before “Security Considerations” section)

6. Manageability Considerations

This document generalises PCEP to allow path setup methods other than RSVP-TE 
to be used by the network.  It is possible that, in a given network, multiple 
path setup methods will be used.  It is also possible that not all devices will 
support the same set of path setup methods.  Managing networks that combine 
multiple path setup methods may therefore raise some challenges from a 
configuration and observability point of view.

Each document that introduces a new path setup type to PCEP must include a 
manageability section.  The manageability section must explain how operators 
can manage PCEP with the new path setup type.  It must address the following 
questions, which are generally applicable when working with multiple path setup 
types in PCEP.

  *   What are the criteria for when devices will use the new path setup type 
in PCEP, and how can the operator control this?
  *   How can the network be migrated to the new path setup type, and are there 
any backwards compatibility issues that operators need to be aware of?
  *   Are paths set up using the new path setup type intended to coexist with 
other paths over the long term and, if so, how is this situation managed with 
PCEP?
  *   How can operators verify the correct operation of PCEP in the network 
with respect to the new path setup type?  Which fault conditions must be 
reported to the operators?
  *   Are there any existing management interfaces (such as YANG models) that 
must be extended to model the operation of PCEP in the network with respect to 
the new path setup type?

See [RFC 6123] for further guidance on how to write manageability sections in 
PCEP standards-track documents.

END NEW

+ [RFC 6123] is added as an informative reference.

Many thanks
Jon



From: Dan Romascanu [mailto:droma...@gmail.com]
Sent: 03 March 2018 10:57
To: Jonathan Hardwick 
Cc: ops-...@ietf.org; pce@ietf.org; i...@ietf.org; 
draft-ietf-pce-lsp-setup-type@ietf.org
Subject: Re: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08



On Fri, Mar 2, 2018 at 7:15 PM, Jonathan Hardwick 
> 
wrote:
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 

[Pce] Agenda for IETF 101

[Dhruv Dhody]

Hi WG,

You might have noticed that the WG agenda is up at - 
https://datatracker.ietf.org/meeting/101/materials/agenda-101-pce
We are meeting on Tuesday afternoon after Lunch!

Presenters,

We have a tight agenda, please note the allocated time for your presentation 
and please prepare presentation material accordingly and set some time aside 
for Q
Please send the slides to your chairs/secretary by Sunday 1900 Local London 
time.

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