date:20171121

Re: [Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06

2017-11-21 Thread Jonathan Hardwick

Hi Julien

Many thanks for the speedy review!  Please see a few answers below, marked with 
[Jon].  (All other comments are accepted.)
I will hold the document mark-ups until WGLC ends.

Cheers
Jon


-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: 21 November 2017 17:08
To: draft-ietf-pce-lsp-setup-t...@ietf.org
Cc: pce@ietf.org
Subject: Shepherd's Review of draft-ietf-pce-lsp-setup-type-06

Hi,

Thank you for this new version of the I-D, it has greatly improved and 
clarifies former loose zones. Please find my review below.

--
Abstract
---
- s/traffic engineering paths (TE paths)/Traffic Engineering paths (TE paths)/
- I wonder about the expansion of "TE path" above: why not "Engineered"
instead of "Engineering"? (This is global to the I-D, and beyond... RFC 
Editor's list includes both.)
- s/label switched paths (LSPs)/Label Switched Paths (LSPs)/
--
Status
---
- "https://; was introduced in -05, but has now disappeared.
--
1. Introduction
---
- s/Path Computation Element Protocol/Path Computation Element communication 
Protocol/

- OLD
path setup type needs to be either explicitly indicated or implied in the 
appropriate PCEP messages (when necessary)...
   NEW
path setup type needs to be explicitly indicated in the appropriate PCEP 
messages, unless RSVP-TE type is meant (omission implying this type)...
--
3. Path Setup Type Capability TLV
---
- s/Initialization phase/initialization phase/
- I though the discussion on the list was about using a bitmap to identify 
supported PSTs: any reason why it is now a list of raw octets?

[Jon] We did discuss a bit field on the list.  The PST field is an 8-bit value, 
so a naive implementation of a bit field would use 32 bytes.  This seems 
wasteful given we only have two values defined so far (possibly 3 with the 
up-coming IPv6-SR draft).  I then looked at some schemes to shorten the bit 
field, e.g. by truncating it, but the result seemed more complicated to encode 
than just listing the path setup types.  (I also didn't much like having a PST 
known both by a value and by a bit field position.)  So I opted to list the 
PSTs.  IMO it's not a problem given the low number of PSTs we expect (could be 
a case of famous last words!)  What do you think of this tradeoff?


- The definition of length and padding mixes the words "octet" and "bytes", 
depending on the field (probably to due to text coming from RFC 5440). 
Consistency would be welcome (the comment appears to be applicable beyond this 
section).

[Jon] Let's standardize on bytes, per RFC 5440.



--
4. Path Setup Type TLV
---
- Figure 2 explicitly includes the codepoint for the "Type" (28), the "Length" 
field should be treated similarly (4).
- The last sentence of section 4 puzzles me. If the PATH-SETUP-TYPE TLV is not 
supported, the PCEP peer cares little if it was "recognized" or not. If both 
sub-cases are commonly handled by ignoring, an implementation always including 
the RSVP-TE PST will be able to interwork with an implementation knowing about 
the TLV without actually supporting it; the current text turns this situation 
into an error.
(Note also that RFC 5440 does not distinguish unrecognized and unsupported in 
TLV processing rules.)

[Jon] I think you are right. The same also applies to the final sentence of 
section 3, I believe.


- In case my previous comment does not fly, 3 more nits:
  * s/recognizes the TLV but does not support the TLV/recognizes the TLV but 
does not support its use/
  * s/send PCErr/send a PCErr message/
  * Error-Type is 2, would not 4 fit better?
--
5. Operation
---
- s/Initialization phase/initialization phase/
- s/MUST infer/MUST consider/  [explicit => nothing to infer]
- The text says multiple times "unless the intended PST is RSVP-TE, in which 
case it MAY omit the PATH-SETUP-TYPE TLV". This is inconsistent with section 4: 
"It is RECOMMENDED that a PCEP speaker omits the TLV if the PST is RSVP-TE." 
Please choose between MAY and SHOULD, and align.

[Jon] I think our intent is MAY, so we can reword the text in section 4 to "A 
PCEP speaker MAY omit the TLV if the PST is RSVP-TE."



--

Cheers,

Julien

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

[Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06

2017-11-21 Thread Julien Meuric

Hi,

Thank you for this new version of the I-D, it has greatly improved and
clarifies former loose zones. Please find my review below.

--
Abstract
---
- s/traffic engineering paths (TE paths)/Traffic Engineering paths (TE
paths)/
- I wonder about the expansion of "TE path" above: why not "Engineered"
instead of "Engineering"? (This is global to the I-D, and beyond... RFC
Editor's list includes both.)
- s/label switched paths (LSPs)/Label Switched Paths (LSPs)/
--
Status
---
- "https://; was introduced in -05, but has now disappeared.
--
1. Introduction
---
- s/Path Computation Element Protocol/Path Computation Element
communication Protocol/

- OLD
path setup type needs to be either explicitly indicated or implied in
the appropriate PCEP messages (when necessary)...
   NEW
path setup type needs to be explicitly indicated in the appropriate PCEP
messages, unless RSVP-TE type is meant (omission implying this type)...
--
3. Path Setup Type Capability TLV
---
- s/Initialization phase/initialization phase/
- I though the discussion on the list was about using a bitmap to
identify supported PSTs: any reason why it is now a list of raw octets?
- The definition of length and padding mixes the words "octet" and
"bytes", depending on the field (probably to due to text coming from RFC
5440). Consistency would be welcome (the comment appears to be
applicable beyond this section).
--
4. Path Setup Type TLV
---
- Figure 2 explicitly includes the codepoint for the "Type" (28), the
"Length" field should be treated similarly (4).
- The last sentence of section 4 puzzles me. If the PATH-SETUP-TYPE TLV
is not supported, the PCEP peer cares little if it was "recognized" or
not. If both sub-cases are commonly handled by ignoring, an
implementation always including the RSVP-TE PST will be able to
interwork with an implementation knowing about the TLV without actually
supporting it; the current text turns this situation into an error.
(Note also that RFC 5440 does not distinguish unrecognized and
unsupported in TLV processing rules.)
- In case my previous comment does not fly, 3 more nits:
  * s/recognizes the TLV but does not support the TLV/recognizes the TLV
but does not support its use/
  * s/send PCErr/send a PCErr message/
  * Error-Type is 2, would not 4 fit better?
--
5. Operation
---
- s/Initialization phase/initialization phase/
- s/MUST infer/MUST consider/  [explicit => nothing to infer]
- The text says multiple times "unless the intended PST is RSVP-TE, in
which case it MAY omit the PATH-SETUP-TYPE TLV". This is inconsistent
with section 4: "It is RECOMMENDED that a PCEP speaker omits the TLV if
the PST is RSVP-TE." Please choose between MAY and SHOULD, and align.
--

Cheers,

Julien

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

Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

2017-11-21 Thread stephane.litkowski

Sounds reasonable.

Thanks

-Original Message-
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com] 
Sent: Tuesday, November 21, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
Cc: MEURIC Julien IMT/OLN
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Hi Stephane

Many thanks for the comment.  This text is a compromise to accommodate 
implementations of the previous version of the draft that have already been 
deployed.  Those implementations do not send PATH-SETUP-TYPE-CAPABILITY in the 
OPEN.  Instead, they send PCEP-SR-CAPABILITY.  Hence, to interoperate with 
those versions, a new implementation can use the presence of PCEP-SR-CAPABILITY 
to infer support of SR, rather than PATH-SETUP-TYPE-CAPABILITY.  In other 
words, this is for backwards compatibility.  It is discussed explicitly in the 
new version of draft-ietf-pce-segment-routing.

If you think the wording below can be improved for clarity, then please let me 
know!

Cheers
Jon

-Original Message-
From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] 
Sent: 20 November 2017 15:32
To: Jonathan Hardwick ; pce@ietf.org
Cc: MEURIC Julien IMT/OLN 
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Hi Jon,

Thanks for the update.
One comment regarding this paragraph:
"If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
   speaker MUST infer that the peer supports path setup using at least
   RSVP-TE.  The PCEP speaker MAY also infer that the peer supports
   other path setup types, but the means of inference are outside the
   scope of this document."

Why not enforcing here ? I mean if a PCEP speaker uses a PST that was not 
advertised in the capability TLV, the PST is rejected by a PCError.
During the OPEN message, peers may agree on the PST to be used on the session 
based on the common subset.

What's your opinion on that ?

Brgds,

Stephane

-Original Message-
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Monday, November 20, 2017 16:07
To: pce@ietf.org
Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS
Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Dear PCE WG

This new revision of the LSP setup type draft makes the following changes.

1) Added a capability TLV for the OPEN object and rules for processing it, as 
discussed in the attached thread. This is to address Julien's WGLC comment that 
there was no way for a PCEP speaker to express that it doesn't support RSVP-TE 
as a path setup type.

2) Made the path setup type explicit for anything other than RSVP-TE paths 
(where absence of TLV implies RSVP-TE).  This is to address Stephane's recent 
comment to the list.

3) Updated the IANA / code point text to reflect that we have had an early 
allocation.

4) Made some editorial fixes and clarifications.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 20 November 2017 14:59
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : Conveying path setup type in PCEP messages
Authors : Siva Sivabalan
  Jeff Tantsura
  Ina Minei
  Robert Varga
  Jon Hardwick
Filename: draft-ietf-pce-lsp-setup-type-06.txt
Pages   : 10
Date: 2017-11-20

Abstract:
   A Path Computation Element can compute traffic engineering paths (TE
   paths) through a network that are subject to various constraints.
   Currently, TE paths are label switched paths (LSPs) which are set up
   using the RSVP-TE signaling protocol.  However, other TE path setup
   methods are possible within the PCE architecture.  This document
   proposes an extension to PCEP to allow support for different path
   setup methods over a given PCEP session.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Pce mailing list
Pce@ietf.org

Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

2017-11-21 Thread Jonathan Hardwick

Hi Stephane

Many thanks for the comment.  This text is a compromise to accommodate 
implementations of the previous version of the draft that have already been 
deployed.  Those implementations do not send PATH-SETUP-TYPE-CAPABILITY in the 
OPEN.  Instead, they send PCEP-SR-CAPABILITY.  Hence, to interoperate with 
those versions, a new implementation can use the presence of PCEP-SR-CAPABILITY 
to infer support of SR, rather than PATH-SETUP-TYPE-CAPABILITY.  In other 
words, this is for backwards compatibility.  It is discussed explicitly in the 
new version of draft-ietf-pce-segment-routing.

If you think the wording below can be improved for clarity, then please let me 
know!

Cheers
Jon

-Original Message-
From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] 
Sent: 20 November 2017 15:32
To: Jonathan Hardwick ; pce@ietf.org
Cc: MEURIC Julien IMT/OLN 
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Hi Jon,

Thanks for the update.
One comment regarding this paragraph:
"If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
   speaker MUST infer that the peer supports path setup using at least
   RSVP-TE.  The PCEP speaker MAY also infer that the peer supports
   other path setup types, but the means of inference are outside the
   scope of this document."

Why not enforcing here ? I mean if a PCEP speaker uses a PST that was not 
advertised in the capability TLV, the PST is rejected by a PCError.
During the OPEN message, peers may agree on the PST to be used on the session 
based on the common subset.

What's your opinion on that ?

Brgds,

Stephane

-Original Message-
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Monday, November 20, 2017 16:07
To: pce@ietf.org
Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS
Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Dear PCE WG

This new revision of the LSP setup type draft makes the following changes.

1) Added a capability TLV for the OPEN object and rules for processing it, as 
discussed in the attached thread. This is to address Julien's WGLC comment that 
there was no way for a PCEP speaker to express that it doesn't support RSVP-TE 
as a path setup type.

2) Made the path setup type explicit for anything other than RSVP-TE paths 
(where absence of TLV implies RSVP-TE).  This is to address Stephane's recent 
comment to the list.

3) Updated the IANA / code point text to reflect that we have had an early 
allocation.

4) Made some editorial fixes and clarifications.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 20 November 2017 14:59
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : Conveying path setup type in PCEP messages
Authors : Siva Sivabalan
  Jeff Tantsura
  Ina Minei
  Robert Varga
  Jon Hardwick
Filename: draft-ietf-pce-lsp-setup-type-06.txt
Pages   : 10
Date: 2017-11-20

Abstract:
   A Path Computation Element can compute traffic engineering paths (TE
   paths) through a network that are subject to various constraints.
   Currently, TE paths are label switched paths (LSPs) which are set up
   using the RSVP-TE signaling protocol.  However, other TE path setup
   methods are possible within the PCE architecture.  This document
   proposes an extension to PCEP to allow support for different path
   setup methods over a given PCEP session.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans

Re: [Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06

[Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06

Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

4 matches

Site Navigation

Mail list logo

Footer information