[Pce] NomCom Call for Volunteers

[julien . meuric]

Hi all,

FYI

The IETF tools development team identified an error in the interface 
between the IETF registration system and the datatracker that mistakenly 
marked people as volunteers for the 2024 NomCom. (Please note that 
volunteering via the registration system is not offered for IETF 120 
registration.)


This error was corrected, and the fix was deployed on June 4. The 
correction for the bug can be viewed at 
https://github.com/ietf-tools/datatracker/pull/7484.


We have removed the incorrect volunteer records as of June 5. However, 
this has led to a severely reduced number of eligible volunteers. Please 
review your status and consider volunteering for NomCom 2024-2025. 
Please check your status at 
https://datatracker.ietf.org/accounts/profile/ after signing in under 
the "NomCom Eligible" section,. If you have already explicitly 
volunteered using the datatracker, you will see "You have volunteered 
for the Nominating Committee 2024/2025.” If you are not yet volunteered, 
you will see a Volunteer button.


You can also volunteer via
CLICK HERE TO VOLUNTEER: https://datatracker.ietf.org/nomcom/volunteer

or directly emailing Dean Bogdanovic at nomcom-chair-2...@ietf.org

Thanks to everyone who has volunteered so far. However, we currently 
have only eligible 100 volunteers. We need many more. So, please, please 
volunteer.


Dean Bogdanovic
nomcom-chair-2...@ietf.org



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Publication has been requested for draft-ietf-pce-pcep-yang-25

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of draft-ietf-pce-pcep-yang-25 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-pcep-yang/


___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Shepherd Review of draft-ietf-pce-pcep-yang

[julien . meuric]

Hi Dhruv,

Thanks for addressing my comments. The new version looks good to me.

Please note however that idnits shouts because of too long lines: have 
you tried circumvent it?


Cheers,

Julien


On 17/05/2024 08:51, Dhruv Dhody wrote:


HI Julien,

On Thu, May 16, 2024 at 7:57 PM  wrote:

Dear authors of draft-ietf-pce-pcep-yang,

I've reviewed the aforementioned document to prepare its publication
request. The I-D is almost ready to move forward and only has minor
issues and nits that should be addressed before sending it to the
IESG.

Minor issues:
- The introduction doesn't mention the ietf-pcep-stats module though
it's defined in the body of the I-D; a brief additional sentence
would
be welcome.


Dhruv: Added "Further, this document also includes the PCEP statistics 
YANGmodule "ietf-pcep-stats" which provides statistics, counters 
andtelemetry data."


- For SR, the leaf "msd-limit" (page 45) is a boolean that should be
renamed to be understandable, e.g. into "no-msd-limit" or
"ignore-msd".


Dhruv: changed to "no-msd-limit".

- On page 46, in the H-PCE section, there's a "if Stateful GMPLS is
enabled" left instead of "if H-PCE is enabled.


Dhruv: thanks for spotting that

- Section 7.1 about TLS should be deeply summarized and rather
point to
the referenced document (pointer to be updated).


Dhruv: Changed to -- "The PCC acting as the TLS client opens the TLS 
connection and the PCE acting as the TLS server listens for incoming 
connections as per TLS specifications ([RFC8446] and [RFC5246]). 
[RFC8253] specifies the StartTLS procedure in PCEP that initiates the 
TLS connection before exchanging PCEP messagesthus the identity 
verification is completed before the PCEP sessionis established."


- On page 51, in the description of the hexadecimal case, I don't
think
the 2 long sentences about the rationale should be included there; if
the authors consider it necessary, it may be included in the text
body
of the draft.


Dhruv: The text/approach is borrowed from RFC 8177. I prefer to keep it.

- On page 59, similar comment about the sync-timer description, which
I'd shorten into the following:
   "The value of SyncTimer in seconds is used in the
    case of synchronized path computation request
    using the SVEC object. If after the expiration of
    the SyncTimer all the path computation requests
    have not been received, a protocol error is
    triggered and the PCE must cancel the whole set
    of path computation requests.
    Zero means that the PCEP entity does not use the
    SyncTimer."


Dhruv: Thanks. Updated.

- On page 69, about path key, the name of the leaf "pcc-original"
feels
odd, how about "originator-pcc" instead?


Dhruv: I changed it to pcc-requester and used "original" in the 
description to march the text in RFC 5520.


          leaf pcc-requester {
            type leafref {
              path "/pcep/entity/peers/peer/addr";
            }
            description
              "Reference to PCC peer address that
              issued the original request that led
              to the creation of the path-key.";
          }

Nits:
- Page 11: s/system generated entity index/system-generated entity
index
- P.11: s/the local entity is PCE it/the local entity is a PCE, it
- P.11: s/dead-timer in YANG is called DeadTimer in the protocol
specification/DeadTimer in the protocol specification is called
dead-timer in YANG/
- P.16: s/learn PCE in the network via IGP discovery/learn a PCE
address
in the network via the IGP discovery/
- P.28-30: There are several bullets points in the descriptions
fields
that would benefit from semicolons at each line end.

Dhruv: I used a comma instead for readability

- P.40: s/maybe relevant/may be relevant/
- P.44: s/PCE triggered/PCE-triggered/  [twice]
- P.49: s/instance specific data/instance-specific data/
- P.105: s/this document also include/this document also includes/


Dhruv: Ack!

Thanks for your review! New version -24 is posted.

Diff: 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pcep-yang-23=draft-ietf-pce-pcep-yang-24=--html 



Regards,
Dhruv


Best regards,

Julien

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Implementation of PCEP YANG

[julien . meuric]

Hi all,

As a shepherd of draft-ietf-pce-pcep-yang, I'd be happy to know if you 
have an implementation of the PCEP YANG module specified in the I-D, or 
if you have plans to do so.

You may of course share your answer privately if you wish.

Thank you,

Julien



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Shepherd Review of draft-ietf-pce-pcep-yang

[julien . meuric]

Dear authors of draft-ietf-pce-pcep-yang,

I've reviewed the aforementioned document to prepare its publication 
request. The I-D is almost ready to move forward and only has minor 
issues and nits that should be addressed before sending it to the IESG.


Minor issues:
- The introduction doesn't mention the ietf-pcep-stats module though 
it's defined in the body of the I-D; a brief additional sentence would 
be welcome.
- For SR, the leaf "msd-limit" (page 45) is a boolean that should be 
renamed to be understandable, e.g. into "no-msd-limit" or "ignore-msd".
- On page 46, in the H-PCE section, there's a "if Stateful GMPLS is 
enabled" left instead of "if H-PCE is enabled.
- Section 7.1 about TLS should be deeply summarized and rather point to 
the referenced document (pointer to be updated).
- On page 51, in the description of the hexadecimal case, I don't think 
the 2 long sentences about the rationale should be included there; if 
the authors consider it necessary, it may be included in the text body 
of the draft.
- On page 59, similar comment about the sync-timer description, which 
I'd shorten into the following:

  "The value of SyncTimer in seconds is used in the
   case of synchronized path computation request
   using the SVEC object. If after the expiration of
   the SyncTimer all the path computation requests
   have not been received, a protocol error is
   triggered and the PCE must cancel the whole set
   of path computation requests.
   Zero means that the PCEP entity does not use the
   SyncTimer."
- On page 69, about path key, the name of the leaf "pcc-original" feels 
odd, how about "originator-pcc" instead?


Nits:
- Page 11: s/system generated entity index/system-generated entity index
- P.11: s/the local entity is PCE it/the local entity is a PCE, it
- P.11: s/dead-timer in YANG is called DeadTimer in the protocol 
specification/DeadTimer in the protocol specification is called 
dead-timer in YANG/
- P.16: s/learn PCE in the network via IGP discovery/learn a PCE address 
in the network via the IGP discovery/
- P.28-30: There are several bullets points in the descriptions fields 
that would benefit from semicolons at each line end.

- P.40: s/maybe relevant/may be relevant/
- P.44: s/PCE triggered/PCE-triggered/  [twice]
- P.49: s/instance specific data/instance-specific data/
- P.105: s/this document also include/this document also includes/


Best regards,

Julien



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

[julien . meuric]

Hi all,

For an experimental document, we have a decent level of support and no 
objection. Every author has responded to the IPR check. The I-D is thus 
adopted by the PCE WG.

@authors: Please, resubmit it as draft-ietf-pce-pcep-ls-00.

Thanks,

Julien


On 04/04/2024 18:18, Julien Meuric wrote:

Hi all,

We have a long history around PCEP-LS. The rough consensus has been to 
progress it as experimental within the PCE WG, which makes more sense 
than an independent submission.
As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to 
become a PCE WG document? Please share your feedback using the PCE 
mailing list, including your comments and especially your rationales 
in case you're opposed.


Thank you,

Julien

---
[1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Fwd: IPR poll for draft-dhodylee-pce-pcep-ls

[julien . meuric]

Forwarding to the list.



-- Original Message --
From: "Sivabalan, Siva" 
Date: 15/04/2024 01:07 BST
Subject: RE: [**EXTERNAL**] FW: [Pce] IPR poll for 
draft-dhodylee-pce-pcep-ls


I am not aware of any IPR applicable to this draft that should be 
disclosed in accordance with IETF IPR rules.


Thanks,

Siva



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

[julien . meuric]

Hi all,

We have a long history around PCEP-LS. The rough consensus has been to 
progress it as experimental within the PCE WG, which makes more sense 
than an independent submission.
As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to become 
a PCE WG document? Please share your feedback using the PCE mailing 
list, including your comments and especially your rationales in case 
you're opposed.


Thank you,

Julien

---
[1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Éric Vyncke's No Objection on charter-ietf-pce-07-04: (with COMMENT)

[julien . meuric]

Hi John,

I agree with most changes but the one below. If we get rid of the 
MPLS-specific langage, then I feel the term "router" isn't generic 
enough. Depending on the data plane technology, the head-end/ingress may 
indeed be referred to as a ROADM, a cross-connect, a bridge, a switch, 
etc. I think terms like "node" or "network element" would resolve that 
issue.


Thanks,

Julien


On 14/12/2023 17:10, John Scudder wrote:

I went ahead and made these changes, they’re in version 07-05. Chairs, please 
take a look and let me know if you’re fine with this version. If so, the 
approval process is complete and I’ll notify the Secretariat.

Thanks,

—John


On Dec 14, 2023, at 9:56 AM, Eric Vyncke (evyncke)  wrote:

[...]

2) in the same vein, the 2nd paragraph is only about (G)MPLS with terms like
LSR and LSP.

As in,

OLD:
In this architecture path computation does not necessarily occur on
the head-end (ingress) LSR, but on some other path computation entity
that may not be physically located on each head-end LSR. The TEAS
Working Group is responsible for defining and extending architectures
for Traffic Engineering (TE) and it is expected that the PCE and TEAS
WGs will work closely together on elements of TE architectures that
utilize PCE.

NEW:
In this architecture path computation does not necessarily occur on
the head-end (ingress) router, but on some other path computation entity
that may not be physically located on each head-end router. The TEAS
Working Group is responsible for defining and extending architectures
for Traffic Engineering (TE) and it is expected that the PCE and TEAS
WGs will work closely together on elements of TE architectures that
utilize 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 autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Lars Eggert's No Objection on charter-ietf-pce-07-04: (with COMMENT)

[julien . meuric]

Hi John,

I guess Lars points "native" out because it appears in the milestones. 
It's there because it's reusing the title of the associated draft, which 
is a reference to the title of RFC 8821...


As I'm not a "native" English speaker, I can't really evaluate how much 
offensive the term is. I also see that the NIST table [1] is rather 
pragmatic and includes an example of "language taken directly from that 
external specification" (on terms that should clearly be precluded). So 
I wonder how much effort should be put on that change...


Thanks,

Julien


[1] 
https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1



On 14/12/2023 15:46, John Scudder wrote:

I don't see the word "native" in the charter text?

John


On Dec 14, 2023, at 8:02 AM, Lars Eggert via Datatracker  
wrote:



Lars Eggert has entered the following ballot position for
charter-ietf-pce-07-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/charter-ietf-pce/__;!!NEt6yMaO-gk!CS86MpyLAch3FBrrIHUnybIAvaSiSxNIJnzru9PIKMOslJrRBg6FT0ZuyRO_PbZq2Fn3e2k3e48x$



--
COMMENT:
--

# GEN AD review of charter-ietf-pce-07-04

CC @larseggert

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://urldefense.com/v3/__https://www.rfc-editor.org/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!CS86MpyLAch3FBrrIHUnybIAvaSiSxNIJnzru9PIKMOslJrRBg6FT0ZuyRO_PbZq2Fn3e8cFfj-W$
  for background and more
guidance:

* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
   `intrinsic`, `original`

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: 
https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!CS86MpyLAch3FBrrIHUnybIAvaSiSxNIJnzru9PIKMOslJrRBg6FT0ZuyRO_PbZq2Fn3e6kYFONU$
[ICT]: 
https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!NEt6yMaO-gk!CS86MpyLAch3FBrrIHUnybIAvaSiSxNIJnzru9PIKMOslJrRBg6FT0ZuyRO_PbZq2Fn3e7EYScuX$
[IRT]: 
https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!CS86MpyLAch3FBrrIHUnybIAvaSiSxNIJnzru9PIKMOslJrRBg6FT0ZuyRO_PbZq2Fn3e-z1ASAx$






Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Publication has been requested for draft-ietf-pce-pceps-tls13-02

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of draft-ietf-pce-pceps-tls13-02 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-pceps-tls13/


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

Re: [Pce] 2nd WGLC for draft-ietf-pce-pceps-tls13

[julien . meuric]

Hi all,

This 2nd WG LC has ended. No concerns have been expressed. Thanks Adrian 
and Andrew for reviewing.


@authors: It will probably be caught later in the process but make sure 
to address Adrian's comment as part of the next revision.


Thanks,

Julien


On 09/11/2023 18:13, Julien Meuric wrote:

Dear PCE WG,

As suggested by Sean during the WG meeting today, this message starts 
a 2nd WG last call on draft-ietf-pce-pceps-tls13-02 [1]. Please, 
express any comments you have about the latest revision of this 
document (diff in [2]) using the PCE mailing list..


This WGLC will end on Friday 24th November 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/
[2] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pceps-tls13-01=draft-ietf-pce-pceps-tls13-02=--html






smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 2nd WGLC for draft-ietf-pce-pceps-tls13

[julien . meuric]

Dear PCE WG,

As suggested by Sean during the WG meeting today, this message starts a 
2nd WG last call on draft-ietf-pce-pceps-tls13-02 [1]. Please, express 
any comments you have about the latest revision of this document (diff 
in [2]) using the PCE mailing list..


This WGLC will end on Friday 24th November 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/
[2] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pceps-tls13-01=draft-ietf-pce-pceps-tls13-02=--html



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Early Code Point Allocation for draft-ietf-pce-sr-bidir-path

[julien . meuric]

Hi all,

No concerns have been expressed about this early allocation. We'll thus 
proceed to the next step.


Thanks,

Dhruv & Julien


On 28/07/2023 15:58, Julien Meuric wrote:

Hi WG,

We have received a request from the authors of 
draft-ietf-pce-sr-bidir-path for an early code point allocation on the 
association type referred to in 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-11#name-iana-considerations


RFC 7120 requires to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.
c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or 
believes that early allocation is not appropriate for any other 
reason, please send an email to the PCE mailing list explaining why. 
If the chairs hear no objections by Monday August 21st, we will kick 
off the early allocation request.


Thanks!

Dhruv & Julien





smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Fwd: WGLC for draft-ietf-pce-pceps-tls13-01

[julien . meuric]

Hi all,

This LC has ended. A few comments have been shared (thank you Stéphane). 
@Authors: please, resolve them.


In the meantime, we'll proceed with RtgDir and SecDir review.

Thanks,

Julien


 Forwarded Message 
Date:   Tue, 5 Sep 2023 11:09:38 +0200
From:   Julien Meuric 


Dear PCE WG,

This message starts a 2-week WG last call on 
draft-ietf-pce-pceps-tls13-01 [1]. Please, be express any comments you 
have about this document using the PCE mailing list.


This WGLC will end on Wednesday 20th September 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] WGLC for draft-ietf-pce-pceps-tls13-01

[julien . meuric]

Dear PCE WG,

This message starts a 2-week WG last call on 
draft-ietf-pce-pceps-tls13-01 [1]. Please, be express any comments you 
have about this document using the PCE mailing list.


This WGLC will end on Wednesday 20th September 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Early Code Point Allocation for draft-ietf-pce-sr-bidir-path

[julien . meuric]

Hi WG,

We have received a request from the authors of 
draft-ietf-pce-sr-bidir-path for an early code point allocation on the 
association type referred to in 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-11#name-iana-considerations


RFC 7120 requires to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.
c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or 
believes that early allocation is not appropriate for any other reason, 
please send an email to the PCE mailing list explaining why. If the 
chairs hear no objections by Monday August 21st, we will kick off the 
early allocation request.


Thanks!

Dhruv & Julien



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

[julien . meuric]

Hi PCE WG,

We have clear support to adopt this work as a WG item. Thank you, all.

@Authors: Please submit the I-D as draft-ietf-pce-stateful-pce-vendor-00 
when the submission tool reopens (starting next Saturday).


Cheers,

Dhruv & Julien


On 20/06/2023 09:46, Julien Meuric wrote:

Hi all,

It has been a while since draft-dhody-pce-stateful-pce-vendor started 
to document how to extend the scope of RFC 7470. It is now time to 
consider its adoption by the WG.
Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to 
become a PCE work item? Please express your support and/or concerns 
using the mailing list.


Thanks,

Dhruv & Julien


[1] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-vendor




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] IPR Poll on draft-dhody-pce-stateful-pce-vendor

[julien . meuric]

Hi Authors,

In preparation for WG adoption on this draft, we'd like all authors and 
contributors to confirm on the list that they are in compliance with 
IETF IPR rules.

Please respond (copying the mailing list) to say one of:
- I am not aware of any IPR applicable to this draft that should be 
disclosed in accordance with IETF IPR rules.
- I am aware of the IPR applicable to this draft, and it has already 
been disclosed to the IETF.
- I am aware of IPR applicable to this draft, but that has not yet been 
disclosed to the IETF. I will work to ensure that it will be disclosed 
in a timely manner.


Thanks,

Julien


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] IPR Poll on draft-dhody-pce-stateful-pce-vendor

[julien . meuric]

Hi Authors,

In preparation for WG adoption on this draft, we'd like all authors and 
contributors to confirm on the list that they are in compliance with 
IETF IPR rules.

Please respond (copying the mailing list) to say one of:
- I am not aware of any IPR applicable to this draft that should be 
disclosed in accordance with IETF IPR rules.
- I am aware of the IPR applicable to this draft, and it has already 
been disclosed to the IETF.
- I am aware of IPR applicable to this draft, but that has not yet been 
disclosed to the IETF. I will work to ensure that it will be disclosed 
in a timely manner.


Thanks,

Julien


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

[julien . meuric]

Hi all,

It has been a while since draft-dhody-pce-stateful-pce-vendor started to 
document how to extend the scope of RFC 7470. It is now time to consider 
its adoption by the WG.
Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to 
become a PCE work item? Please express your support and/or concerns 
using the mailing list.


Thanks,

Dhruv & Julien


[1] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-vendor

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Publication has been requested for draft-ietf-pce-local-protection-enforcement-07

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of 
draft-ietf-pce-local-protection-enforcement-07 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-local-protection-enforcement/


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

[Pce] Publication has been requested for draft-ietf-pce-binding-label-sid-10

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of draft-ietf-pce-binding-label-sid-10 
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-binding-label-sid/


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

[Pce] Publication has been requested for draft-ietf-pce-pcep-extension-for-pce-controller-09

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of 
draft-ietf-pce-pcep-extension-for-pce-controller-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-pcep-extension-for-pce-controller/


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

[Pce] Publication has been requested for draft-ietf-pce-pcep-flowspec-09

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of draft-ietf-pce-pcep-flowspec-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-pcep-flowspec/


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

[Pce] Publication has been requested for draft-ietf-pce-association-diversity-08

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of 
draft-ietf-pce-association-diversity-08 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-association-diversity/

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

[Pce] Publication has been requested for draft-ietf-pce-stateful-path-protection-07

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of 
draft-ietf-pce-stateful-path-protection-07 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-path-protection/

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

[Pce] Publication has been requested for draft-ietf-pce-association-group-08

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of draft-ietf-pce-association-group-08 
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-association-group/

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

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Julien Meuric]

Hi Jeff,

You're right. I certainly don't want to change the specification, nor to
add another ambiguity. I was just looking for a mnemonic to mitigate the
confusion pointed out by Martin, to be considered between bracket
(leaving the definition as is).
Would "limit-blind" make sense?

Cheers,

Julien


On 06/01/2019 20:20, Jeff Tantsura wrote:
> Hi Julien,
>
> Happy New Year to you too.
> There’s a slight difference between limitless (e.g. unlimited) and
> limit has not been been imposed (not configured/unknown/etc).
> I think  “limitless” doesn’t convey the exact meaning. In simple terms
> - if L=1, don’t use MSD as a constraint in the path computation.
>
> Thanks,
> Jeff
>
> On Fri, Jan 4, 2019 at 02:28  > wrote:
>
> Hi guys and happy new year! :-)
>
> Would it temper the confusion below if we added the term
> "limitless" to
> the L flag definition (section 5.1.1.)?
>
> My 2 cents,
>
> Julien
>
>
> On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > I believe it is too late to change but I find L=1 meaning "no
> limit" is *very* confusing. For me L stands for Limit and when L=1
> there is a limit, when L=0 there is none.
> >
> > [Jon] Agree, both that it is confusing and too late to change :-)
>

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

Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-auto-bandwidth

[Julien Meuric]

Hi,

This LC has ended, without pointed out issue. We will then move to
shepherd review.

Thanks,

Julien


On 13/12/2018 14:29, Julien Meuric wrote:
> Hi all,
>
> This e-mail starts a 3-week PCE WG Last Call on
> draft-ietf-pce-stateful-pce-auto-bandwidth-08. Please share your reviews
> and comments using the mailing list by Friday January 5, 2019.
>
> Thank you,
>
> 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

[Pce] WG Last Call on draft-ietf-pce-stateful-pce-auto-bandwidth

[Julien Meuric]

Hi all,

This e-mail starts a 3-week PCE WG Last Call on
draft-ietf-pce-stateful-pce-auto-bandwidth-08. Please share your reviews
and comments using the mailing list by Friday January 5, 2019.

Thank you,

Julien

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

[Pce] Adoption Poll for draft-lazzeri-pce-residual-bw

[Julien Meuric]

Dear WG,

We discussed about draft-lazzeri-pce-residual-bw a couple of times
during past IETF meetings. At that time, those in the room who had read
it looked quite interested, but they were just a few. We now request a
feedback from the list: do you support the adoption of
draft-lazzeri-pce-residual-bw as a starting point for a PCE work item?
(https://tools.ietf.org/html/draft-lazzeri-pce-residual-bw-01)

Please respond to the list, including your reasons if you do not support.

Thanks

Julien


P.S.: We are aware that the latest version of the I-D has expired, but
an adoption would solve that and a lack of interest may help the authors
focus their effort on something else than a simple timer reset.

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

Re: [Pce] Visibility into the Chairs' Queue of Work

[Julien Meuric]

Hi Adrian,

Thank you for the buttkick, this is sometimes useful, especially when
(temporarily) transitioning from a couple of chairs kicking each other
to a single one struggling at self-kicking. This is another opportunity
to greet Jon again for his valuable work, both on stage and behind the
scene. :-)

Good news: our secretary agrees to implement your proposal on the WG's
wiki. Knowing how proactive Dhruv can be, please find the resulting page
here: https://trac.ietf.org/trac/pce/wiki

About draft-zhang-pce-resource-sharing (which isn't really the last
adoption poll), thanks for the reminder. I've synchronized with Jon and
will follow-up on the corresponding thread.

Last but not least, thank you for the thorough reviews you've recently
shared on the WG list: this is highly valuable to make I-Ds ready to
progress and is clearly helpful to successfully go through the further
steps in the process. Even if not thanked each time, your work is always
appreciated.

Cheers,

Julien


On 13/12/2018 10:33, Adrian Farrel wrote:
> Hi Chairs,
>
> I'm trying to think of ways that the WG participants can get a bet view of
> what process work is pending and when to expect it.
>
> At each IETF meeting you present a useful slide showing the "WG documents at
> or near last call"
>
> For example, at IETF 103 you showed
> https://datatracker.ietf.org/meeting/103/materials/slides-103-pce-1-administ
> rivia-and-wg-status-00.pdf which indicates that we had four documents
> pending shepherd review.
> - inter-area-as-applicability
> - stateful-pce-p2mp
> - hierarchy-extensions
> - association-group
> .and four documents in the queue for WG last call
> - stateful-pce-auto-bandwidth
> - applicability-actn
> - pcep-stateful-pce-gmpls
> - stateful-hpce
>
> This list is helpful because those of us who want to see work move along can
> get in early and do our "last call reviews" even before last call is
> started.
>
> Looking at the datatracker and the mailing list, I see that:
> - one draft expired ages ago
> - one draft has been waiting for the shepherd for 6 weeks
> - one has been waiting for the shepherd for only 1 week (seems reasonable
> :-)
> - one has been waiting for the shepherd for 12 weeks or more
> I also see that none of the four WG last calls has been started.
>
> Now, I really don't want to be pissy here: I appreciate the work that the
> chairs' do and I know that no one ever got rich being a WG chair. But I
> wonder whether we could unstick this a bit and move the drafts along.
>
> Maybe it would help to put this list on the WG wiki so that we can see in a
> little bit more detail what the next steps are and who we should be
> prodding. If there's a reason why a document is hung, then it would be a
> good place to put a note so that we can see. It would also help set our
> expectations with regard to ordered lists and timing.
>
> Alternatively, some additional details could easily be put in the tracker
> using the sub-states, tags, and history comments. That wouldn't be as easy
> to see the whole list and understand the ordering challenges, but it would
> keep all the information in one place.
>
>
> At the same time, I'm trying to work out which documents are queued for
> consideration for WG adoption. Now, I know that we can all work on drafts at
> any time and don't have to wait for them to be adopted before considering
> them seriously, but it is a bit confusing not being able to tell which
> documents are waiting for process and when they are likely to be considered.
>
> I looked in the datatracker and I don't see any use of the sub-states/tags
> that can indicate "Candidate for WG Adoption". Do the chairs have a list of
> documents that they are considering for adoption? Sharing that list (such as
> on the wiki) would help save the authors from pestering the chairs at every
> opportunity, and would also set expectations for the working group with
> regard to timing and ordering. The last adoption poll I can see on the list
> ended on October 26th (with the chairs calling "no conclusion") - was that
> really the only document ready for consideration?
>
>
> I think this could be made to a go a lot more smoothly with greater
> visibility into the queue, and a wiki page would be cheap and easy to
> maintain. I bet the WG secretary would be willing to do this (Hi, Dhruv :-)
> but if not, I can set it up and the chairs can add the data.
>
> Thanks for your consideration.
>
> Best,
> Adrian
> --
> Fairy tales from North Wales brought to you for Christmas
> https://www.feedaread.com/profiles/8604/
> Available from your favourite online bookseller.
> Or contact me to receive a signed copy by mail.
>

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

[Pce] Fwd: [spring] IP unnumbered SR-adjacency encoding issue in PCEP-SR & IDR-SR

[Julien Meuric]

FYI, from the Spring list.


 Forwarded Message 
Date:   Wed, 12 Dec 2018 11:56:26 +0800
From:   peng.sha...@zte.com.cn
To: ms...@cisco.com, stef...@previdi.net
CC: spr...@ietf.org


Dear authors,

I found that draft-ietf-pce-segment-routing-14 only defined SR-ERO
(NT=5) for IPv4 unnumbered adjacency, IPv6 absent. 

On the contrary, draft-ietf-idr-segment-routing-te-policy-05 only
defined Segment (type=7 or 10) for IPv6 unnumbered adjacency, IPv4
absent. In this document Segment (type=5) looks like only for P2P adjacency.

Could you give a more clarification?


Thanks

Deccan

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

[Pce] Publication has been requested for draft-ietf-pce-gmpls-pcep-extensions-12

[Julien Meuric]

Julien Meuric has requested publication of 
draft-ietf-pce-gmpls-pcep-extensions-12 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-gmpls-pcep-extensions/

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

Re: [Pce] WG Last Call for draft-ietf-pce-hierarchy-extensions

[Julien Meuric]

Hi,

This LC has ended. Thank you Adrian for the review. Authors, please
resolve the open items and publish a revision accordingly.

Cheers,

Julien


Sep. 06, 2018 - julien.meu...@orange.com:
> Hi all,
> 
> This message initiates a 2-week WG last call for
> draft-ietf-pce-hierarchy-extensions-05. Please review and share your
> feedback on the PCE mailing list. This LC will end on Thursday
> September, 20.
> 
> Regards,
> 
> Jon & 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

[Pce] IPR Check on draft-ietf-pce-hierarchy-extensions

[Julien Meuric]

Dear authors of draft-ietf-pce-hierarchy-extensions,

Could you please send an email to the PCE mailing list saying whether
you are aware of any IPR that applies to
draft-ietf-pce-hierarchy-extensions and, if so, if it has been disclosed
in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378
for more details.)
If you are not aware of any IPR that applies, please reply saying "I am
not aware of any IPR that applies to this draft".

A reply is required from each of you before we can proceed with
publication request.

Thanks,

Jon & Julien

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

[Pce] WG Last Call for draft-ietf-pce-hierarchy-extensions

[Julien Meuric]

Hi all,

This message initiates a 2-week WG last call for
draft-ietf-pce-hierarchy-extensions-05. Please review and share your
feedback on the PCE mailing list. This LC will end on Thursday
September, 20.

Regards,

Jon & Julien

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

Re: [Pce] WG LC of draft-ietf-pce-association-group

[Julien Meuric]

 
  
some new comments:
  
  

  

   If a PCEP speaker receives ASSOCIATION in PCReq message, and the
   association is not known (association is not configured, or created
   dynamically, or learned from a PCEP peer), it MUST return a PCErr
   message with Error-Type 26 (Early allocation by IANA) "Association
   Error" and Error-Value 4 "Association unknown".
 
  
  
I am confused, that forbids
  PCReq on LSP with unknown association. If the
  P bit is set, maybe, bit its likely
  association-dependent.
  
  
 
[[Dhruv
Dhody2]] Use of a path computation
request message to create a new
association state is not correct for a
message that supposed to be for
stateless PCE model. Ofcourse if PCE is
aware of the association group already
carrying this information as a part of
PCReq is fine!
  
A
PCReq message on the other hand can
notify PCE of a new association, and PCE
would store the association state as
part of LSP-DB. Does that make sense? 
 
Regards,
Dhruv
 
  
  

  

  

   
  Thanks for your patience. 
   
  Regards,
  Dhruv
   
  Thanks, Cyril  

  
  

  
 

  On 1 February
2018 at 10:38, <stephane.litkow...@orange.com>
wrote:
  
Support
  
  -Original Message-
      From: Pce [mailto:pce-boun...@ietf.org]
  On Behalf Of Julien Meuric
  Sent: Thursday, February 01,
  2018 15:10
  To: pce@ietf.org
  Subject: [Pce] WG LC of
  draft-ietf-pce-association-group
  
  Hi all,
  
  This message initiates a
  2-week WG last call for
  draft-ietf-pce-association-group-04.
  Please review and share your
  feedback on the PCE mailing
  list. This LC will end on
  Thursday February, 15.
  
  Regards,
  
  Jon & Julien
  
___
  Pce mailing list
  Pce@ietf.org
  https://www.ietf.org/mailman/listinfo/pce
  
_
  
 

Re: [Pce] 2nd WG Last Call of draft-ietf-pce-segment-routing

[Julien Meuric]

Hi all.

This last call has ended. It seems that nobody objects to this revision.

FYI, Dhruv has agreed to be the shepherd of this document.

Thanks,

Jon & Julien


Jul. 23, 2018 - :
> Hi all,
>
> The I-D extending PCEP for segment routing has faced substantial changes
> during its latest revisions. To benefit from review before sending to
> the IESG, this message initiates a new WG last call on
> draft-ietf-pce-segment-routing-12. This LC will end on Monday July 30,
> 11:59pm HST.
>
> Please share your comments using the PCE list.
>
> Regards,
>
> Jon & Julien
>

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

[Pce] Shepherd Review of draft-ietf-pce-gmpls-pcep-extensions

[Julien Meuric]

Hi all,

Please find below my review of draft-ietf-pce-gmpls-pcep-extensions, dug
out of the backlog. Let us discuss the main identified issues first, we
will look at the minor comments and nits afterwards.

Generally speaking, the main items to improve are related to
clarification. Normative behavior and especially error handling often
need more accurate descriptions to limit ambiguities. Sorting error
values may also be deserved, especially with respect to existing error
types.

--
Section 2.2
---
- s/The PCE MAY try to follow/The PCE SHOULD  try to follow
- s/Otherwise, the PCE MAY use/Otherwise, the PCE MUST use/
--
Section 2.3
---
- The bidirectional symmetric bandwidth is defined with 2 MUST's and a
MUST NOT: the error case is not specified if the 3 requirements are not
followed. I guess a sentence pointing to Error-Type 10/Value TBA-14
would address this.
- s/asymmetric bandwidth, it SHOULD/asymmetric bandwidth, it MUST/
--
Section 2.4
---
- The following text is unnecessary and should be dropped:
"A PCC SHOULD be allowed to request a set of TE-LSP also in case of GMPLS
 bandwidth specification.
 The LOAD-BALANCING has the same limitation as the BANDWIDTH for GMPLS
 networks."
- Like above, the bidirectional symmetric bandwidth with LOAD-BALANCING
is defined with 2 MUST's and a MUST NOT: the error case is not specified
if the 3 requirements are not followed. I guess a sentence pointing to a
relevant error (Type 10, new Value?) would address this.
- s/while specifying load balancing constraints, it SHOULD/while
specifying load balancing constraints, it MUST/
- About the last paragraph ("For example [...] corresponding request"):
  * Have you considered moving into appendix?
  * Codepoints are mentioned instead of TBA-2, -4...
--
Section 2.5.1
---
- s/restriction are not always/restriction may not be/

OLD:
   Endpoint type 0 MAY be accepted by
   the PCE, other endpoint type MAY be supported if the PCE
   implementation supports P2MP path calculation.  A PCE not supporting
   a given endpoint type MUST respond with a PCErr with error code "Path
   computation failure", error type "Unsupported endpoint type in END-
   POINTS Generalized Endpoint object type".
NEW:
   A PCE may accept only Endpoint Type 0: Endpoint Types 1-4 apply if the
   PCE implementation supports P2MP path calculation. A PCE not
   supporting a given Endpoint Type SHOULD respond with a PCErr with
   Error Type 4, Value TBD "Unsupported endpoint type in END-POINTS
   Generalized Endpoint object type". As per [RFC5440], a PCE unable to
   process Generalized Endpoints may respond with Error Type 3 or 4,
   Value 2.

OLD:
   A PCE not supporting one of those TLVs in a PCReq MUST respond with a
   PCRep with NO-PATH with the bit "Unknown destination" or "Unknown
   source" in the NO-PATH-VECTOR TLV, the response SHOULD include the
   ENDPOINT object in the response with only the TLV it did not
   understood.
NEW:
   When receiving a PCReq, a PCE unable to resolve the identifier in one of
   those TLVs MUST respond using a PCRep with NO-PATH and set the bit
   "Unknown destination" or "Unknown source" in the NO-PATH-VECTOR TLV.
   The response SHOULD include the ENDPOINT object with only the TLV it
   did not understand.

- s/error type="Path computation failure"/Error Type 4/
--
Section 2.5.2.5.
---
- The I-D has chosen to allocate 2 TLV codepoints for LABEL-SET and
SUGGESTED-LABEL-SET. Any reason not to use just one including a
strict/loose bit to distinguish them?
- s/allocated on the first link/allocated on the first endpoint/
- The text "has the same encoding as the LABEL-SET TLV, it" is redundant
and should be dropped.

OLD:
  This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET
  TLV Set and ignored on receipt. This Label MAY be reused. The R
  bit of the RP object MUST be set.
NEW:
  The R bit of the RP object MUST be set to 1. In a SUGGESTED-LABEL-SET
  TLV, this bit SHOULD be set to 0 and ignored on receipt.

- In the 1st paragraph on page 19 ("Several LABEL_SET TLVs [...] be
ignored"), it seems that SHOULD's should be MUST's.
--
Sections 2.6. & 2.7
---
- To be consistence with RFC 7896, both sentences about the L bit should
be dropped.
--
Sections 3 & 5.5
---
- Several errors (e.g., TBD-15, -28, -29...) may be moved to Type 4.
---

Best regards,

Julien


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

Re: [Pce] Eric Rescorla's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Julien Meuric]

Hi Eric,

As a shepherd, I can address your 2nd concern without waiting for the
authors.

For both defined TLVs, the backward compatibility is addressed by the
last sentence of sections 3 and 4:
"  If a PCEP speaker does not recognize the PATH-SETUP-xxx
   TLV, it MUST ignore the TLV in accordance with ([RFC5440])."

The exact wording will be updated to address other comments, e.g.:
- MUST -> will,
- Make it explicit that an ignored TLV is similar to an absent TLV, and
implies the only existing method before this I-D, i.e. X == RSVP-TE
signaling (cf. Martin's comment).

Thanks,

Julien


Apr. 04, 2018 - e...@rtfm.com:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-pce-lsp-setup-type-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Please expand RP and SRP on first use.
> 
> What is the backward compatibility story here? I.e., say I only support method
> X and the peer doesn't know about this TLV at all? How will it behave?
> 
> 

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

[Pce] Early Code Point Allocation for draft-ietf-pce-stateful-pce-p2mp

[Julien Meuric]

Hi all,

As mentioned during our session in London, we have received a request
from the authors of draft-ietf-pce-stateful-pce-p2mp for an early code
point allocation.

RFC 7120 requires to meet the following criteria to proceed:

   b.  The format, semantics, processing, and other rules related to
   handling the protocol entities defined by the code points
   (henceforth called "specifications") must be adequately described
   in an Internet-Draft.
   c.  The specifications of these code points must be stable; i.e., if
   there is a change, implementations based on the earlier and later
   specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria, or
believes that early allocation is not appropriate for any other reason,
please send an email to the PCE mailing list explaining the reasons.  If
the chairs hear no objections by next Tuesday, April 3, we will kick off
the early allocation request.

Best regards,

Jon & Julien

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

[Pce] Building the PCE Agenda for IETF 101

[Julien Meuric]

Hi all,

The PCE meeting for London is tentatively scheduled on Tuesday early
afternoon (same time as RIFT). If you need some face-to-face time to
progress some work, please send a slot request to the chairs and
secretary by Monday March 5 including:
- the draft(s) you want to discuss,
- the expected presenter name,
- the requested duration, including question time as part of the slot,
- the reason why you need face-to-face time as opposed to using the
mailing list (open 24/7).

Thank you,

Jon & Julien

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

Re: [Pce] WG LC of draft-ietf-pce-association-group

[Julien Meuric]

Hi,

This WG LC has ended. Authors, some comments have been raised (at least
by Cyril): please address them.

Thanks,

Jon & Julien


Feb. 01, 2018 - Julien Meuric:
> Hi all,
>
> This message initiates a 2-week WG last call for
> draft-ietf-pce-association-group-04. Please review and share your
> feedback on the PCE mailing list. This LC will end on Thursday February, 15.
>
> Regards,
>
> Jon & 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] Adoption Poll for draft-raghu-pce-lsp-control-request

[Julien Meuric]

Hi all,

Thanks to those who responded to the poll. It confirms the consensus we
originally had in the room. The I-D is adopted as a WG document.

Authors, please submit draft-ietf-pce-lsp-control-request-00.

Cheers,

Jon & Julien


Jan. 22, 2018 - julien.meu...@orange.com:
> Hi all,
> 
> Back in Prague, draft-raghu-pce-lsp-control-request raised clear
> interest. Since then, the authors have done their homework, including
> the removal of suggested values. Let us now share the question with the
> whole WG: do you think draft-raghu-pce-lsp-control-request is a good
> foundation for a PCE WG item?
> Please send your responses to the PCE list, including rationales in case
> of disagreement.
> 
> Thanks,
> 
> Jon & 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] WG Last Call for draft-ietf-pce-segment-routing-11

[Julien Meuric]

Hi all,

This LC has ended.
Adrian, Dhruv (on HAST time), thanks a lot for your valuable reviews.
Authors, please address identified issues and update the I-D.

Cheers,

Julien


Jan. 15, 2018 - Julien Meuric:
> Dear PCE WG,
>
> Best wishes for this new year, full of interoperable specifications. Let
> us begin by resuming our work in progress.
>
> This message starts a 2-week WG last call for
> draft-ietf-pce-segment-routing-11. Please send your feedback on the I-D
> to the PCE mailing list by Monday January 29.
>
> Regards,
>
> Jon & 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

[Pce] Adoption Poll for draft-raghu-pce-lsp-control-request

[Julien Meuric]

Hi all,

Back in Prague, draft-raghu-pce-lsp-control-request raised clear
interest. Since then, the authors have done their homework, including
the removal of suggested values. Let us now share the question with the
whole WG: do you think draft-raghu-pce-lsp-control-request is a good
foundation for a PCE WG item?
Please send your responses to the PCE list, including rationales in case
of disagreement.

Thanks,

Jon & Julien

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

[Pce] IPR Check on draft-ietf-pce-segment-routing

[Julien Meuric]

Dear authors of draft-ietf-pce-segment-routing,

Could you please send an email to the PCE mailing list saying whether
you are aware of any IPR that applies to draft-ietf-pce-segment-routing
and, if so, if it has been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not
aware of any IPR that applies, please reply saying "I am not aware of
any IPR that applies to this draft".

A reply is required from each of you before we can proceed.

Thanks,

Julien

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

[Pce] WG Last Call for draft-ietf-pce-segment-routing-11

[Julien Meuric]

Dear PCE WG,

Best wishes for this new year, full of interoperable specifications. Let
us begin by resuming our work in progress.

This message starts a 2-week WG last call for
draft-ietf-pce-segment-routing-11. Please send your feedback on the I-D
to the PCE mailing list by Monday January 29.

Regards,

Jon & Julien

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

[Pce] Publication has been requested for draft-ietf-pce-lsp-setup-type-07

[Julien Meuric]

Julien Meuric has requested publication of draft-ietf-pce-lsp-setup-type-07 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-lsp-setup-type/

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

[Pce] Fwd: Final IPR Check for draft-ietf-pce-lsp-setup-type

[Julien Meuric]

Ina, Siva,

I cannot find your response to this IPR poll. Please send your feedback
to the list as soon as possible.

Thanks,

Julien


 Forwarded Message 
Date:   Tue, 16 May 2017 09:55:23 +0200
From:   Julien Meuric <julien.meu...@orange.com>


Dear authors,

Could you please send an email to the PCE mailing list saying whether
you are aware of any IPR that applies to draft-ietf-pce-lsp-setup-type
and, if so, if it has been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not
aware of any IPR that applies, please reply saying "I am not aware of
any IPR that applies to this draft".

A reply is required from each of you before we can proceed.

Many thanks,

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] [Technical Errata Reported] RFC4674 (5192)

[Julien Meuric]

Hi,

It looks like the errata form has become a playground. ADs, please feel
free to reject.

Thanks,

Julien


Nov. 30, 2017 - rfc-edi...@rfc-editor.org:
> The following errata report has been submitted for RFC4674,
> "Requirements for Path Computation Element (PCE) Discovery".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5192
> 
> --
> Type: Technical
> Reported by: Amitkumar 
> 
> Section: 463846379684
> 
> Original Text
> -
> Ok
> 
> Corrected Text
> --
> Ok
> 
> Notes
> -
> 
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC4674 (draft-ietf-pce-discovery-reqs-05)
> --
> Title   : Requirements for Path Computation Element (PCE) 
> Discovery
> Publication Date: October 2006
> Author(s)   : J.L. Le Roux, Ed.
> Category: INFORMATIONAL
> Source  : Path Computation Element
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 

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

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

[Julien Meuric]

Hi Jon,

You are welcome. All open issues are about to get closed. Please see
[JM] below.

Thanks,

Julien


Nov. 21, 2017 - jonathan.hardw...@metaswitch.com:
> 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
> 
> 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?

[JM] I do not have any strong opinion on this. If noone objects, it is
reasonable to go that way from where we stand.
Have you considered a more explicit figure, e.g. the following?

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PST#1 | PST#2 |   Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//   (variable size)   //
|   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 
> 
> - 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.

[JM] OK

> 
> --
> 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.

[JM] I agree. Good catch!

> 
> 
> - 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 m

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

[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

[Pce] Second WG Last Call for draft-ietf-pce-lsp-setup-type

[Julien Meuric]

Dear PCE WG,

Considering the concerns discussed on the list after the 1st WG Last
Call, especially about the backward compatibility of the additional TLV
(please see Jon's change list), this message starts a 2nd LC on
draft-ietf-pce-lsp-setup-type-06. It will end on Monday December 4.

Thanks for your careful reviews,

Julien

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

Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Julien Meuric]

  
  
Hi,

IMHO, the correct wording lies in between. RFC 5440 set the default
for PCEP ("A PCEP-ERROR object is used to report a PCEP error").
Further specification (e.g. RFC 8231) MAY add message-specific
behavior, but I think it is wrong to mandate a new behavior for each
new message. I would thus suggest :

   If the PCE does not understand or support an
experimental object with
   the P flag set in the Object Header, in the Path
Computation Request
   message (PCReq), the entire PCEP message is
rejected and PCE responds
   with a PCErr message with Error-Type="Unknown
Object" or "Not
   supported object" as described in [RFC5440].
Otherwise, the object is
   ignored. Message-specific behavior MAY be
specified (e.g., [RFC8231]
   defines rules for a PCC to handle an unknown object in an Update
   (PCUpd) message).



My 2 cents,

Julien


Nov. 13, 2017 - dhruv.dh...@huawei.com:


  
  
   


  

  
 
Section 5
 
The following
paragraph does not tell the whole story.
 
   A
PCE that does not recognize an experimental PCEP object,
will
  
reject the entire PCEP message and send a PCE error
message with
  
Error- Type="Unknown Object" or "Not supported object"
as described
   in
[RFC5440].
 
If the P flag is
clear in the object header, then the PCE MAY ignore the
object instead of generating this error message. Also,
you do not discuss what a PCC would do on receipt of a
PCUdp or PCInitiate containing an unrecognised
experimental object – it is inconsistent that you don’t
cover these cases.  (FWIW, RFC 8231 is a bit ambiguous
about what a PCC should do about the PCUpd. Section 6.2
says that a PCErr should be sent, but then it refers to
section 7.3.3, which says that a PCRpt should be sent.
Hmmm.)
 
[[[Dhruv Dhody]]] Yes. How about I update
to this – 
 
   If the PCE does
not understand or support an experimental object with
   the P flag set
in the Object Header, in the Path Computation Request
   message
(PCReq), the entire PCEP message is rejected and PCE
responds
   with a PCErr
message with Error-Type="Unknown Object" or "Not
   supported
object" as described in [RFC5440].  Otherwise the object
is
   ignored.  In
case of stateful PCE messages [RFC8231], the P flag is
   ignored and the
unknown object handling is as per the stateful PCE
   extensions.
 
And let’s try to handle the inconsistency
in RFC 8231 with an errata perhaps? And handle
PCE-initiated during AUTH48? 
 
[Jon] I think this is OK, but if we are
just going to point the reader at RFC8231, then we might
as well do the same with RFC5440, rather than duplicate
its text.  And we should write something that allows for
the possibility that more message types may be relevant
in future.  How about
 
   If a PCEP
speaker does not understand or support an experimental
object
   then the way it
handles this situation depends on the message type.
   For example, a
PCE handles an unknown object in the Path Computation
Request
   (PCReq) message
according to the rules of [RFC5440].  A PCC handles an
   unknown object
in an Update (PCUpd) message according to the rules of
[RFC8231]
   and, in an LSP
Initiate Request (PCInitiate) message, according to the
rules of
 
 [I-D.ietf-pce-pce-initiated-lsp].  Any document that
adds a new PCEP message
   type must
specify how to handle unknown objects on that message.
 
Note that this last sentence is not an
RFC2119 MUST because it defines author behaviour, not
device behaviour.
  

  


  


___
Pce mailing list

Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

[Julien Meuric]

Hi Stéphane,

Of course, that type of request would only make sense when the PCE knows
about supported types. Static configuration could allow that, but the
update that Jon is going to include in the I-D allows the PCE to be
aware of the supported capabilities by the PCC.

Anyway, I am fine with leaving that open for the future. I just want to
make sure that we have consensus on the exact scope of the document
before we freeze it.

Thanks for the feedback,

Julien


Nov. 16, 2017 - stephane.litkow...@orange.com:
> Hi Julien,
> 
>> Over a PCEP session supporting multiple types, we do not have a mean to send 
>> a PCReq leaving the type selection to the PCE (no TLV implying type 0).
> 
> I do not see the use case here.
>  In addition, I'm not sure that the PCE always know what are the setup types 
> actively supported by the PCC. As a consequence it may pick one which is not 
> supported and the LSP setup will fail. For SR, the PCE may know it through 
> the SR cap, but for RSVP, can the PCE deduce it from another information ?
> 
> 
> Brgds,
> 
> 
> -Original Message-
> From: Julien Meuric [mailto:julien.meu...@orange.com] 
> Sent: Thursday, November 16, 2017 17:28
> 
> Hi,
> 
> Glad to see we are converging. To make sure we are on the same page (solution 
> (2) referring to a shortcut), the conclusion is that, as soon as PST is not 0 
> (i.e. RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt 
> and PCInitiate: is that right?
> 
> This leads me to another question. Over a PCEP session supporting multiple 
> types, we do not have a mean to send a PCReq leaving the type selection to 
> the PCE (no TLV implying type 0). Do we consider a mean to support that? 
> (Could be 0xFF or a flag from the "Reserved" field.)
> 
> Thanks,
> 
> Julien
> 
> 
> Nov. 16, 2017 - jonathan.hardw...@metaswitch.com:
>>
>> Hi Stephane
>>
>>  
>>
>> OK, let's go with solution (2).  That is, if the PATH-SETUP-TYPE is 
>> not present in a message, then it unambiguously means that the path 
>> setup type is RSVP-TE.  Then implementations don't have to try to 
>> infer the path setup type from other objects or previous messages.
>>
>>  
>>
>> I am revising draft-ietf-pce-lsp-setup-type at the moment to address 
>> an earlier comment from Julien, so I will include this clarification 
>> in the next revision.
>>
>>  
>>
>> Thanks for the input!
>>
>> Cheers
>>
>> Jon
>>
>>  
>>
>>  
>>
>> *From:*stephane.litkow...@orange.com
>> [mailto:stephane.litkow...@orange.com]
>> *Sent:* 15 November 2017 13:52
>>
>>  
>>
>> Hi Jon,
>>
>>  
>>
>> Thanks for your feedback.
>>
>> I see two possibilities here.
>>
>>  1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be
>> inferred from the latest one received (in a PCInitiate or in a
>> PCUpd). When initiating an LSP, the PCInitiate contains the PST to
>> let the PCC know about the path type. Then, it can be omitted in
>> further PCUpd except when the PCE wants to change the path type.
>> At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value
>> and then it does not need to include it in further updates until
>> the PCE needs to change it again.
>>  2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd.
>>
>>  
>>
>> IMO, solution 2) is easier for implementations and operation.
>>
>>  
>>
>> Brgd,
>>
>>  
>>
>> Stephane
>>
>>  
>>
>>  
>>
>> *From:*Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
>> *Sent:* Wednesday, November 15, 2017 09:28
>> *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org <mailto:pce@ietf.org>
>> *Subject:* RE: Clarifications on PST handling in 
>> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>>
>>  
>>
>> I think it should be acceptable for the PCUpd not to include the 
>> PATH-SETUP-TYPE, with the implication that there is no change to the 
>> path type.
>>
>>  
>>
>> Although I'm not convinced it would be a good idea operationally, I 
>> don't think there's any need to prevent the path type changing on the 
>> PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is, 
>> draft-ietf-pce-lsp-setup-type, as a base draft, should allow that 
>> flexibility.  A given device may choose not to allow that, of course.
>>
>>  
>>
>> Does that sound reasonable?
>>
>> Cheers
>>
>&g

Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

[Julien Meuric]

Hi,

Glad to see we are converging. To make sure we are on the same page
(solution (2) referring to a shortcut), the conclusion is that, as soon
as PST is not 0 (i.e. RSVP-TE), we always include the PST TLV in PCReq,
PCRep, PCUpd, PCRpt and PCInitiate: is that right?

This leads me to another question. Over a PCEP session supporting
multiple types, we do not have a mean to send a PCReq leaving the type
selection to the PCE (no TLV implying type 0). Do we consider a mean to
support that? (Could be 0xFF or a flag from the "Reserved" field.)

Thanks,

Julien


Nov. 16, 2017 - jonathan.hardw...@metaswitch.com:
>
> Hi Stephane
>
>  
>
> OK, let’s go with solution (2).  That is, if the PATH-SETUP-TYPE is
> not present in a message, then it unambiguously means that the path
> setup type is RSVP-TE.  Then implementations don’t have to try to
> infer the path setup type from other objects or previous messages.
>
>  
>
> I am revising draft-ietf-pce-lsp-setup-type at the moment to address
> an earlier comment from Julien, so I will include this clarification
> in the next revision.
>
>  
>
> Thanks for the input!
>
> Cheers
>
> Jon
>
>  
>
>  
>
> *From:*stephane.litkow...@orange.com
> [mailto:stephane.litkow...@orange.com]
> *Sent:* 15 November 2017 13:52
>
>  
>
> Hi Jon,
>
>  
>
> Thanks for your feedback.
>
> I see two possibilities here.
>
>  1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be
> inferred from the latest one received (in a PCInitiate or in a
> PCUpd). When initiating an LSP, the PCInitiate contains the PST to
> let the PCC know about the path type. Then, it can be omitted in
> further PCUpd except when the PCE wants to change the path type.
> At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value
> and then it does not need to include it in further updates until
> the PCE needs to change it again.
>  2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd.
>
>  
>
> IMO, solution 2) is easier for implementations and operation.
>
>  
>
> Brgd,
>
>  
>
> Stephane
>
>  
>
>  
>
> *From:*Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> *Sent:* Wednesday, November 15, 2017 09:28
> *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org 
> *Subject:* RE: Clarifications on PST handling in
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>  
>
> I think it should be acceptable for the PCUpd not to include the
> PATH-SETUP-TYPE, with the implication that there is no change to the
> path type.
>
>  
>
> Although I’m not convinced it would be a good idea operationally, I
> don’t think there’s any need to prevent the path type changing on the
> PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is,
> draft-ietf-pce-lsp-setup-type, as a base draft, should allow that
> flexibility.  A given device may choose not to allow that, of course.
>
>  
>
> Does that sound reasonable?
>
> Cheers
>
> Jon
>
>  
>
>  
>
> *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of
> *stephane.litkow...@orange.com 
> *Sent:* 14 November 2017 00:38
> *To:* pce@ietf.org 
> *Subject:* [Pce] Clarifications on PST handling in
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>  
>
> Hi WG,
>
>  
>
> I’m facing an interop issue between two PCEP implementations.
>
> PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1
> in the SRP Object.
>
> PCC from vendor2 handles it correctly and delegates the LSP to the PCE
> using PST=1.
>
> When the PCE sends a PCUpdate message, it does not set the PST TLV in
> the SRP Object.
>
> The PCC rejects the PCUpdate because of a bad ERO subobject type. It
> reads the PCUpdate as having PST type=0.
>
>  
>
> Based on my reading of draft-ietf-pce-lsp-setup-type &
> draft-ietf-pce-segment-routing.
>
> PST draft tells that for the PCE Initiation case, the PCE MAY include
> the PST if the message does not ave any other means of indicating the
> path setup type. SR draft tells “In order to setup an SR-TE LSP using
> SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately
> it does not specify explicitly in which message. From a reading
> perspective, we can understand from “In order to setup” that it
> applies to the PCInitiate message. But nothing tells about the
> PCUpdate message.
>
> However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case
> that: “if the path setup type cannot be unambiguously inferred from
> ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in
> PCRpt and PCUpd messages.”
>
> In our case (PCE initiated) as the LSP has initially been setup
> through a PCInitiate message having the PST TLV, the PCC can infer
> that futher updates will use EROs associated with the same PST.
>
>  
>
> Or do we allow to change the PST through PCUpdate messages which may
> require to  always set the PST ? (moving from RSVP-TE to SR or the
> other way for a particular 

Re: [Pce] Building the PCE Agenda for IETF 100

[Julien Meuric]

Dear WG,

You probably all had a look at the PCE agenda:
https://datatracker.ietf.org/meeting/100/materials/agenda-100-pce/
(thanks Dhruv).

If you have a slot, you are expected to send your slides to the chairs
and secretary by Saturday 11. Please take into account the duration
actually allocated to your slot, including questions.

Thanks,

Jon & Julien


Oct. 20, 2017 - :
> Hi all,
>
> The PCE WG session in Singapore is tentatively scheduled on Monday at
> 3:50pm (facing I2RS).
> If you need meeting time to progress some work, please send a request to
> the chairs and secretary by Sunday October 29, including:
> - the associated I-D(s),
> - the expected presenter,
> - the requested duration,
> - the motivation to request some face-to-face time as opposed to using
> the mailing list to progress your work.
>
> Regards,
>
> Jon & Julien
>

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

Re: [Pce] Genart last call review of draft-ietf-pce-pce-initiated-lsp-10

[Julien Meuric]

Hi Joel,

Any issue with a request to initiate an LSP setup/teardown to a device? ;-)

I agree the name reads odd, but it has been there for some time now and
the WG seems to be fine with it. Besides, it does not prevent anyone to
add better wording in a patch to their favorite decoding software...

Thanks a lot for your review,

Julien


Aug. 11, 2017 - j...@joelhalpern.com:
> Nits/editorial comments:
> It seems odd to have a message for the creation or deletion of an LSP
> called an LSP Initiate Request.

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

Re: [Pce] PCEP as an SDN controller protocol?

[Julien Meuric]

  
  
Hi Daniele,

[Operator hat on.]

I agree on several things you wrote, starting from the answer to
Jon's rhetorical question, which cares more about how much (at least
I've never noticed my co-chair has a short memory).

Nevertheless the sentence below needs to be corrected, because it
happens to be wrong: "optical networks with no control plane" is as
inaccurate as "a fuel car with no battery".
Not relying on the high-end version of this mean to realize the core
task of an equipment must not hide that most (even those Sonet/SDH
ADMs) of the deployed optical devices do (mostly for management
traffic, whose fate PCEP may share)...:
- perform IP forwarding,
- have a routing table,
- run an IGP to populate that routing table,
- run an IGP to advertise their attached addresses,
- support a large set of (IP-based) protocols for various purposes
(e.g., ICMP, DHCP, SSH, SMTP), i.e. squeezing many roles within a
single protocol is a non-goal.

A possible rephrasing could be "networks where the control plane is
limited to background tasks", which reminds that operators deploy
"fully packaged cars", not just "raw wheels with a motor" according
to the misleading scope assumed in the current discussion.

Thanks,

Julien


Jul. 24, 2017 - daniele.ceccare...@ericsson.com:


  
  
It could be the SBI solution for those networks
where there is no control plane (e.g. many NMS driven
optical networks)
  


  


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

[Pce] My Comment on draft-lee-pce-flexible-grid

[Julien Meuric]

Hi,

The discussion during the meeting suggests that I need to clarify my
comment about draft-lee-pce-flexible-grid.

This I-D is very similar to draft-ietf-pce-wson-rwa-ext, which addresses
the exact same problem over a slightly different WDM label space
(running a side-by-side diff between them appears to be very practical).
This new I-D requests the creation of one object and 3 TLVs, which are
identical to the ones created in the WSON.
As a result, I believe the latter should be reused as a starting popint.
Covering the flexi-grid case may just need to allocate new flag in the
object header to identify the WDM type we're dealing with, and document
the flexi-grid-specific assumptions (if any).

Thanks,

Julien

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

Re: [Pce] Building the PCE Agenda for IETF 99

[Julien Meuric]

Hi all,

The tentative agenda for our upcoming meeting is on line since last
week. Without further comments, it will be used as a final version.

Presenters, if you have a slot, please send your slides to the chairs
and secretary by Saturday, 15th.

Thanks,

Jon, JP & Julien


Jun. 23, 2017 - julien.meu...@orange.com:
> Hi all,
> 
> The PCE WG session in Prague is tentatively scheduled on Tuesday 3:50pm
> (facing I2RS).
> If you need meeting time to progress some work, please send a request to
> the chairs and secretary by Monday July 3, including:
> - the associated I-D(s),
> - the expected presenter,
> - the requested duration,
> - the motivation to request some face-to-face time as opposed to using
> the mailing list to progress your work.
> 
> Regards,
> 
> Jon, JP & Julien
> 

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

[Pce] Building the PCE Agenda for IETF 99

[Julien Meuric]

Hi all,

The PCE WG session in Prague is tentatively scheduled on Tuesday 3:50pm
(facing I2RS).
If you need meeting time to progress some work, please send a request to
the chairs and secretary by Monday July 3, including:
- the associated I-D(s),
- the expected presenter,
- the requested duration,
- the motivation to request some face-to-face time as opposed to using
the mailing list to progress your work.

Regards,

Jon, JP & Julien

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

[Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type

[Julien Meuric]

Dear authors,

 

Could you please send an email to the PCE mailing list saying whether
you are aware of any IPR that applies to draft-ietf-pce-lsp-setup-type
and, if so, if it has been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not
aware of any IPR that applies, please reply saying "I am not aware of
any IPR that applies to this draft".

 

A reply is required from each of you before we can proceed.

 

Many thanks,


Julien

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

Re: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04

[Julien Meuric]

Hi all,

This LC has ended. Authors, please resolve the open comment on this I-D
so that we can send it to the IESG.

Thanks,

Jon, JP & Julien


May. 02, 2017 - Julien Meuric:
> Dear all,
>
> The aforementioned I-D has been stable for a while. This message
> initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04.
> Please send your comments to the PCE mailing list by May 15.
>
> Thanks,
>
> Jon, JP & 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] Stateful PCE: inconsistency in "resource limit" text

[Julien Meuric]

Ramon,

Thanks a lot for your feedback, this is very helpful.

Julien


May. 09, 2017 - ramon.casel...@cttc.es:
> On 9/5/17 12:18, Julien Meuric wrote:
>> On the former, we must not forget that:
>> - the use of PCNtf is consistent with the overload case in RFC 5440,
>> - draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG
>> and IETF LCs),
>> - draft-ietf-pce-stateful-pce has early allocated codepoints.
>> As a result, the PCNtf is not an open question in the current case.
> (snip)
> 
> Hi again Julien,
> 
> Thanks for reminding me of the specific question and sorry for diverging
> in multiple ways :) In view of your further comments and draft
> constraints, my preference remains as follows:
> 
> I still consider not being able to complete sync as a serious error and
> I would suggest a MUST close the session, regardless of the actual
> message to indicate such failure.
> 
> Thanks
> R.
> 

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

Re: [Pce] Stateful PCE: inconsistency in "resource limit" text

[Julien Meuric]

Hi Dhruv,

At this stage, it seems a bit late to introduce this change into the
document. However, keeping only "MAY" would allow implementations to
behave the way you suggest. Do we consider your feedback as supporting
"MAY"?

Thanks,

Julien


May. 09, 2017 - dhruv.dh...@huawei.com:
>
> Hi Jon, WG,
>
>  
>
> I feel this was done to differentiate two cases –
>
>  
>
> (1)   The resource limit happened during state synchronization
> (section 5.6) – with MUST close session
>
> (2)   The resource limit happened during normal state report – with
> MAY close session
>
>  
>
> We could make this explicit and differentiate the two scenarios?
>
>  
>
> Regards,
>
> Dhruv
>
>  
>
>  
>
>  
>
> *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick
> *Sent:* 08 May 2017 21:49
>
>  
>
> Hi PCE WG
>
>  
>
> I’ve been tidying up the stateful PCE draft to prepare it for
> publication and I have discovered an inconsistency in how the stateful
> PCE is supposed to handle an overflow of its per-PCC resource limit. 
> In section 5.6 it says:
>
>  
>
>A PCE implementing a limit on the resources a single PCC can occupy,
>
>MUST send a PCNtf message with Notification Type to be allocated by
>
>IANA (Stateful PCE resource limit exceeded) and Notification Value to
>
>be allocated by IANA (Entering resource limit exceeded state) in
>
>response to the PCRpt message triggering this condition in the
>
>synchronization phase and MUST terminate the session.
>
>  
>
> Whereas in section 6.1 it says:
>
>  
>
>A PCE may choose to implement a limit on the resources a single PCC
>can occupy.  If a PCRpt is received that causes the PCE to exceed
>this limit, the PCE MUST notify the PCC using a PCNtf message with
>Notification Type to be allocated by IANA (Stateful PCE resource
>limit exceeded) and Notification Value to be allocated by IANA
>(Entering resource limit exceeded state) and MAY terminate the
>session.
>
>  
>
> These sections are inconsistent because the first says the PCE MUST
> terminate the session whereas the second says the PCE MAY terminate
> the session.
>
>  
>
> Furthermore, in section 8.6, the following notification is defined for
> “exiting resource limit exceeded state”, but this notification is not
> referenced anywhere in the text.
>
>  
>
> Notification-Type  Meaning
>4Stateful PCE resource limit exceeded
>  Notification-value=2:   Exiting resource limit exceeded
>  state
>
>  
>
> Please could I ask all implementers:
>
> -  MUST the PCE terminate the session if its state limit is
> exceeded, or MAY it leave it open?
>
> -  Has anybody implemented the “exiting resource limit
> exceeded state” notification?  If so, how are you using it?
>
>  
>
> Your swiftest answers would be very much appreciated!
>
>  
>
> If I don’t get any contradictory replies, my default action will be to
> say that the session MUST be terminated and to remove the unreferenced
> notification-value.
>
>  
>
> Many thanks
>
> Jon
>
>  
>
>
>
> ___
> 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] Stateful PCE: inconsistency in "resource limit" text

[Julien Meuric]

Hi again Ramon,

We are tackling 2 topics here: the stateful I-D on the table and PCErr
vs. PCNtf at large (see [JM] below).

On the former, we must not forget that:
- the use of PCNtf is consistent with the overload case in RFC 5440,
- draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG
and IETF LCs),
- draft-ietf-pce-stateful-pce has early allocated codepoints.
As a result, the PCNtf is not an open question in the current case.

Then in the text...


May. 09, 2017 - ramon.casel...@cttc.es:
> On 9/5/17 10:35, Julien Meuric wrote:
>> Hi Ramon,
>>
>> Indeed, the I-D used to consider an error for this case, but RFC 5440
>> gives the pace and 2 codepoints were allocated:
>> - PCErr are associated to PCEP issues ("when a protocol error condition
>> is met or when the request is not compliant with the PCEP specification");
>> - PCNtf are typically used for other cases, including PCE state (e.g.
>> overload) and policy (e.g. threshold).
>>
>> Please note also that the current (orphan) text of the I-D allows to use
>> the PCNtf for "Exiting resource limit exceeded state". I am not saying
>> the latter should be kept, but considering this option sustains the idea
>> of having 2 possible messages/behaviors in PCEP.
>
> Hi Julien,
>
> This is indeed making me raise more questions than expected.
>
> - Reading the section I got the feeling that any event preventing to
> reach full sync state caused a PCErr (now PCNtf) and a MUST session
> close. was it the intent?

[JM] Allow me to rephrase a bit: "preventing to reach full sync state
caused an error advertised using a PCNtf". The impact on session closure
is the only discussed topic.

>
> - As a minor comment, I see your point on the PCErr / PCNtf
> "macroscopic use", although I would humbly object, notably in view of
> the whole PCErr 5: policy violation, that includes cases such as
> "global concurrent optimization not allowed" or "objective function
> not allowed" so, while I can agree with your view, IMHO it is not
> black/white.
> In particular, I think you are not fully quoting RFC5440
>
>The PCEP Error message (also referred to as a PCErr message) is sent
>in several situations: when a protocol error condition is met or when
>the request is not compliant with the PCEP specification (e.g.,
>reception of a malformed message, reception of a message with a
>mandatory missing object, policy violation, unexpected message,
>unknown request reference)
>
> It seems to me that policiy violation is a PCErr.  

[JM] You are right, it is not black/white. E.g. there are various types
of policy violations:
- operations the PCEP peer is not allowed to do (it may even be aware
before trying);
- live situation changes, like overload or threshold crossing (here, a
PCC is not necessarily misbehaving but hitting a PCE-local value);
- etc.
Generally speaking, I do not see in RFC 5440 a very strict line
splitting between PCErr and PCNtf, the discussion on ties should happen
on a case by case basis. We should at least avoid to decide based on the
message name. The actual question is: does a given feature match the
5/12 message/object kind or the 6/13 one? An opportunity (even if not
specified) to exit a faced situation (like overload or threshold
crossing) may often suggest to consider PCNtf, but this is not a strict
definition.

> However, the main question is:
>
> - Is not reaching full sync considered a protocol error? (for whatever
> reason, and beyond a single message exchange but more as a
> transactional thing/sequence)  If yes, I would vote for a PCErr / MUST
> close
>
> - If it is not an error (I am not fully aware of the implications)
> then we should allow PCNtf + MAY leave it open. Otherwise, my view
> remains PCErr + MUST close.

[JM] I do not think message type and session closure are so tied. In the
current document, PCNtf is no more questionable. Consequently, can we
consider your statement as a voice for "MAY" in the document?

Thanks,

Julien

>
> Thanks!
> Ramon
>
>
>
>
>
> ___
> 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] WG Last Call of draft-ietf-pce-lsp-setup-type-04

[Julien Meuric]

Hi Dhruv,

Thank you for your feedback, this is valuable.

I fully agree with your first statement: so far, any PCEP peer is
assumed as RSVP-TE-compliant. When no path setup type is explicitly
expressed, this must remain the assumption, I am not questioning the
default.
However, I believe there will be some networks (e.g. SR-enabled) where:
- multiple PCEs may support different capabilities while, in the current
I-D, the only way for a PCC to identify that RSVP-TE is not supported
would be to send a PCReq and get a session-closing "Unsupported path
setup type" error;
- some PCCs are not actually RSVP-TE-capable, thus PCE-initiated TE-LSPs
will also face a session-closing "Unsupported path setup type" error (by
the way, I feel we should not close the session in this case).

I see two ways to address this case with a reasonable effort:
- assume that when path setup types are explicitly expressed (which
remains optional), there is no implicit assumption, thus the RSVP-TE
capability advertisement proposed below;
- stick with this implicit RSVP-TE support by default, which would
require an RSVP-TE-NON-SUPPORT TLV some time.

Assuming we can agree on the requirement, I prefer to add TLVs to
express capabilities rather than disable them. If you believe otherwise,
I wonder if the latter proposal would be an acceptable trade-off.

Cheers,

Julien


May. 03, 2017 - dhruv.i...@gmail.com:
> Hi Julien, 
>
> In my understanding, PCEP sessions are always RSVP-TE capable. 
> One may not want any LSP to be signaled by RSVP-TE, in which case
> PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is
> MUST anyways by SR I-D).   
>
> Also, isnt this, what we have always done with stateless to stateful
> PCE or P2P to P2MP extensions and so on, should we consider
> path-setup-type to be different?  
>
> Just some thoughts, lets see what the authors/WG think...
>
> Regards,
> Dhruv
>  
>
> On Wed, May 3, 2017 at 7:17 PM, Julien Meuric
> <julien.meu...@orange.com <mailto:julien.meu...@orange.com>> wrote:
>
> [Chair hat off]
>
> Authors of draft-ietf-pce-lsp-setup-type,
>
> Reading the I-D, it looks to me that a (small) piece is missing.
> Let us
> assume that I want my PCEP peers to advertise they are both SR-capable
> and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is
> defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we
> should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and
> recommended omission in case of RSVP-TE only.
>
> My 50 cents,
>
> Julien
>
>
> May. 02, 2017 - Julien Meuric:
> > Dear all,
> >
> > The aforementioned I-D has been stable for a while. This message
> > initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04.
> > Please send your comments to the PCE mailing list by May 15.
> >
> > Thanks,
> >
> > Jon, JP & Julien
> >
> > ___
> > Pce mailing list
> > Pce@ietf.org <mailto:Pce@ietf.org>
> > https://www.ietf.org/mailman/listinfo/pce
> <https://www.ietf.org/mailman/listinfo/pce>
> >
>
> ___
> Pce mailing list
> Pce@ietf.org <mailto:Pce@ietf.org>
> https://www.ietf.org/mailman/listinfo/pce
> <https://www.ietf.org/mailman/listinfo/pce>
>
>

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

Re: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04

[Julien Meuric]

[Chair hat off]

Authors of draft-ietf-pce-lsp-setup-type,

Reading the I-D, it looks to me that a (small) piece is missing. Let us
assume that I want my PCEP peers to advertise they are both SR-capable
and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is
defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we
should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and
recommended omission in case of RSVP-TE only.

My 50 cents,

Julien


May. 02, 2017 - Julien Meuric:
> Dear all,
>
> The aforementioned I-D has been stable for a while. This message
> initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04.
> Please send your comments to the PCE mailing list by May 15.
>
> Thanks,
>
> Jon, JP & 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] Status of draft-ietf-pce-wson-rwa-ext

[Julien Meuric]

  
  
Hi Cyril, hi Adrian,

Don't worry, even though we missed several datatracker cycles, the
I-D isn't forgotten and a shepherd has been appointed: me. ;-)

The chairs had decided to apply WFQ over the I-D processing queue.
Considering the low pressure product implementers put on the
interoperability along this I-D (feedback to the chairs welcome on
that), it got preempted to free bandwidth for the stateful I-Ds and
the associated codepoint clash. Now that these are with the IESG, I
should be able to share my review soon (i.e., by next IETF).

Regards,

Julien


Apr. 11, 2017 - cmarga...@juniper.net:


  
  
  
  
  
  
  

  Hi, 
  
  
  From what I can recall, there was no comment pending.
Grep'ing through my archives I found : the following last messages regarding the gmpls
  draft are :
  
  
  Other comments addressed : https://mailarchive.ietf.org/arch/msg/pce/3oswQvIe4THUtUSUnXwKfmfeVmg,
also reflected in https://www.ietf.org/proceedings/94/slides/slides-94-pce-0.pdf

  
  
  
  WG comments addressed: https://mailarchive.ietf.org/arch/msg/pce/vPZsnrCy4kh7H8VaMDz6I-XI8uw
  
  
  
  
  The document status from the slides is Shepherd assigned.
  
  
  I will be happy to address any actions that I can complete
on my side.
  
  
  Cyril


From:
Adrian Farrel 
Sent: Monday, April 10, 2017 4:40:28 PM
  
   

  
  
  Thanks Jon!

Looks like I need to chivvy the authors of
draft-ietf-pce-gmpls-pcep-extensions.

But, oh look! It has expired. A year ago!

Wow! Any archaeologists out there want to dig through the
mail archive to find
out what needed to be done?

Thanks,
Adrian

> -Original Message-
> From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> Sent: 10 April 2017 08:37
> 
> Hi Adrian
> 
> Thanks for checking.  This draft depends normatively on
draft-ietf-pce-gmpls-
> pcep-extensions, which I believe still has some actions
to be completed.  Our
plan
> is to advance both together.
> 
> Cheers
> Jon
> 
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org]
On Behalf Of Adrian Farrel
> Sent: 07 April 2017 18:33
> 
> Hi,
> 
> Did https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext
disappear
> down a crack?
> 
> Looks like WG last call completed and the draft was
updated.
> Also the shepherd write-up was updated.
> 
> Does the big red button need to be pressed to send this
to the AD?
> 
> Thanks,
> Adrian
> 
  


  


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

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Julien Meuric]

Jon, Lionel,

I believe Lionel got confused by the wording introduced in RFC 8051:
- no report, no update means stateless PCE;
- report, no update means passive stateful PCE;
- report and update means active (stateful) PCE.

More details below, [JM].

Thanks for the work,

Julien


Apr. 11, 2017 - jonathan.hardw...@metaswitch.com:
> =
> 
> [LM] active/passive mode are not  advertized in PCEP. s/if active 
> stateful PCE capability was not advertised/if stateful PCE
> capability was not advertised
> 
> Jon> ACK
> 
> =
[JM] NACK! ;-)
Actually, the passive mode is advertised using the
Stateful-capability-object TLV with the U bit unset, the active mode by
setting the U bit.

> =
> 
> Note that even if the update capability has not been advertised, a 
> PCE can still accept LSP Status Reports from a PCC and build and 
> maintain an up to date view of the state of the PCC's LSPs.
> 
> [LM] I don't undersand. Is it not in contradiction with
> 
> "If the PCEP Speaker on the PCE supports the extensions of this
> draft but did not advertise this capability, then upon receipt of a
> PCRpt message from the PCC, it MUST generate a PCErr with error- type
> 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if
>  active stateful PCE capability was not advertised) (see Section
> 8.5) and it SHOULD terminate the PCEP session."
> 
> Or does it mean that there is another way than PCRpt message for the
>  PCC to send LSP status reports to the PCE?
> 
> Jon> ACK.  I think that the statement in the draft is bogus and I 
> propose to delete this sentence from it.
> 
> =
[JM] I do not think that the text is bogus:
- case 1: no advertised capability on update but advertised on report
(i.e. passive stateful) => no error message;
- case 2: no advertised capability on update nor report (i.e. stateless)
=> error.

> =
> 
> [LM] Would it be useful to discover (using another TLV) whether the 
> PCE is an active/passive stateful PCE, as in IGP-based capabilities 
> discovery mechanism?
> 
> Jon> This can be inferred immediately from the U flag in the 
> STATEFUL-PCE-CAPABILITY TLV.  Passive mode is synonymous with not 
> sending / handling PCUpd messages.
> 
> =
[JM] The mechanism is there, but section 7.1.1 may deserve an explicit
use of the "passive/active" terms, to make sure the capability
terminology is aligned with the vocabulary in the IGP section.

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

Re: [Pce] Building the PCE Agenda for IETF 98

[Julien Meuric]

Dear PCE WG,

The agenda for our meeting on Monday is on-line:
https://datatracker.ietf.org/meeting/98/agenda/pce/

As you can see, the amount of slot requests largely exceeds the number
of threads in progress on the _list_. The difference should not be so
large: the _mailing list_ is open 24/7. As a result, we had to identify
priorities by trying to balance between hot topics, new items, active
discussion, recent face-to-face slots, etc.

If your I-D is beyond schedule, the hope for spare time to present is
tiny. Please, make use of the _mailing list_ to introduce your work or
share your progress (which scheduled presenters should do as well).

If you have a main stream slot, please send your slides to the chairs
and secretary by _Friday 24_.

Thank you,

Jon, JP & Julien


Feb. 27, 2017 - Julien Meuric:
> Hi all, > > The PCE WG session in Chicago is tentatively scheduled on Monday >
3:20pm. If you need meeting time to progress some work, please send a >
request to the chairs and secretary by Monday March 13, including: - >
the associated I-D(s), - the expected presenter, - the requested >
duration, - the motivation to request some face-to-face time as >
opposed to using the mailing list to progress your work. > > Please note
as well that Yang work should be directed to the joint >
MPLS/TEAS/CCAMP/PCE session. It is currently scheduled on Friday >
morning and Tarek, as the MPLS secretary, is taking care of the >
corresponding agenda (see Tarek's thread). > > Regards, > > Jon, JP &
Julien >

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

Re: [Pce] draft-ietf-pce-pce-initiated-lsp

[Julien Meuric]

Hi,

This topic was tackled a while ago in the context of
draft-ietf-pce-pce-initiated-lsp:
https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE

It looks like the I-D would benefit from clarification on this matter
before sending it to the IESG. Authors, what to do you think?

Aaron (Cyril?), while keeping feature extensions for another document
(cf. Dhruv's proposal), would you have some clarification text to
propose here?

Thanks,

Julien


Jan. 09, 2017 - jonathan.hardw...@metaswitch.com:
> Hi Aaron
> 
> Thanks.  So actually, I need to backtrack and agree that there is a mechanism 
> defined for a backup PCE to request that an orphaned LSP is delegated to it - 
> I had missed that.
> 
> I am not sure that this implies that the PCC cannot re-delegate of its own 
> free will.  It would be useful to have that clarified in the draft.
> 
> However, given this mechanism exists, it does raise the question about how 
> PCEs should properly cooperate in terms of how orphaned LSPs are detected and 
> who should request ownership.  I know that there is work ongoing in the 
> following draft which discusses co-operation between redundant PCEs.  I am 
> not sure whether your idea is best discussed in the context of that draft or 
> in draft-ietf-pce-pce-initiated-lsp.  Perhaps the authors could chime in?
> https://tools.ietf.org/id/draft-litkowski-pce-state-sync-00.txt
> 
> Best regards
> Jon
> 
> 
> -Original Message-
> From: Aaron Itskovich [mailto:aitsk...@cisco.com] 
> Sent: 05 January 2017 19:30
> 
> Hi Jon,
> 
> Thanks for your reply.
> My interpretation of the following section of the existing 
> draft-ietf-pce-pce-initiated-lsp is that PCC cannot just re-delegate PCE 
> initiated LSP to a PCE.
> 
> 
> 
> In case of PCEP session failure, control over PCE-initiated LSPs
> reverts to the PCC at the expiration of the redelegation timeout.  At
> this point, the LSP is an "orphan" until the expiration of the State
> Timeout timer.  To obtain control of a PCE-initiated LSP, a PCE
> (either the original or one of its backups) sends a PCInitiate
> message, including just the SRP and LSP objects, and carrying the
> PLSP-ID of the LSP it wants to take control of.  Receipt of a
> PCInitiate message with a non-zero PLSP-ID normally results in the
> generation of a PCErr.  If the LSP is an orphan, the PCC MUST NOT
> generate an error and MUST redelegate the LSP to the PCE.  The State
> Timeout timer for the LSP is stopped upon the re-delegation.
> 
> 
> I read it as PCC is not free to delegate PCE initiated LSP even in orphan 
> state, it rather waits (using State Timer) for other PCE server to "adopt" 
> such "orphan" LSP.
> This behavior is different for the PCE initiated LSPs vs PCC initiated LSPs.
> Hence my suggestion was a mechanism that will help redundant PCE servers to 
> discover PCE initiated LSPs that enter "orphan" state and trigger "adoption"
> process which is different then the just re-delegation.
> 
> Thanks
> Aaron
> 
> 
> On 2017-01-05 11:25 AM, Jonathan Hardwick wrote:
>> Hi Aaron
>>
>> Thanks for the comment.  There are no procedures defined that would allow a 
>> PCE to initiate a take-over of an LSP from a PCC.  Rather, the PCC must 
>> delegate the LSP to an appropriate PCE (if the LSP is initiated by a PCE 
>> then it must initially be delegated to that PCE).  The cases you mention 
>> would be resolved by the PCC making a local decision whether or not to 
>> re-delegate the LSP to an alternative PCE.
>>
>> So, I am not sure that the "orphan" flag would be useful to the PCE, at 
>> least not for the purpose that you describe.
>>
>> Best regards
>> Jon
>>
>>
>> -Original Message-
>> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aaron Itskovich
>> Sent: 04 January 2017 20:08
>> To: pce@ietf.org
>> Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp
>>
>>
>> I suggest to add indication that PCE Initiated LSP is orphan to LSP object 
>> in PCReport message. This information will be useful in facilitating 
>> takeover of an orphan LSP by redundant PCE server.
>>
>> Option 1) Adding bit to the LSP flags (L-bit "parentless/orphan") that will 
>> be set in the LSP object of the PCReport message sent when PCE Initiated LSP 
>> becomes orphan as result of connection loss to the PCE server that initiated 
>> this LSP or because such PCE server returns LSP delegation to the PCC to 
>> initiate transfer of LSP "ownership" to another PCE server.
>>
>> Option 2) Adding bit to the LSP flags (D2-bit ) that is set when such LSP is 
>> delegated to any PCE server. In this option PCE receiving report will be 
>> able to derive when PCE Initiated LSP is in orphan state when C flag in the 
>> report is set and the new D2-bit is not set.
>>
>>
>> This proposal (regardless which option 1 or 2 is used ) alows PCC to 
>> propagate "orphan" state for the PCE initiated LSP to all PCE servers.
>> It will help to trigger takeover of a PCE 

[Pce] Poll for Adoption of draft-dhody-pce-association-policy

[Julien Meuric]

Hi all,

Though it is a -00, draft-dhody-pce-association-policy already has a 
long history: thanks to the authors for the common work. During our 
meeting in Seoul, it received some support from the room. We now want to 
know whether the list agrees to adopt it as a foundation for a PCE WG 
document.

Please, share your comments on the mailing list.

Regards,

Julien

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

[Pce] Last IPR Check for draft-ietf-pce-pce-initiated-lsp

[Julien Meuric]

Dear authors of the aforementioned I-D,

Could you please share with the mailing list whether you are aware of 
any IPR that applies to draft-ietf-pce-pce-initiated-lsp and, if so, if 
it has been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 
4879, 3669 and 5378 for more details.)  If you are not aware of any IPR 
that applies, please reply saying “I am not aware of any IPR that 
applies to this draft”.


A feedback from each of you is required to move the document to the IESG.

Best regards,

Jon, JP & Julien

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

[Pce] Building the PCE Agenda for IETF 97

[Julien Meuric]

Hi all,

The preliminary agenda for the IETF in Seoul tentatively schedules the 
PCE session on Wednesday, November 16, at 1:30pm. Should you intend to 
present something during our face-to-face time, please send a request to 
the chairs and secretary by Friday, October 28, including:

- the associated I-D(s),
- the requested duration,
- the expected presenter,
- the rationale for requesting some face-to-face time as opposed to 
discussing using the PCE mailing list.


We will also hold a joint session on Yang work together with the CCAMP, 
TEAS and MPLS WGs. It appears as "CCAMP" and is currently scheduled on 
Monday, November 14, at 3:50pm.


Thanks,

Jon, JP & Julien


P.S.: If your WG I-D does not need a slot this time, please feel free to 
share its status on the mailing.


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

Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[Julien Meuric]

  
  
Hi all,
  
  Chair hat on, I concur with the proposed plan: we need to stick to
  the current scope of the base stateful I-D and fix pending issues
  in there, new proposals like "partial delegation" do require a new
  document.
  
  Thank you Dhruv and Stéphane for being proactive on that,
  
  Julien


Oct. 05, 2016 - :


  
  
  
  
  
Hi Dhruv,
Sudhir
 
I agree that
what is achieved here is a partial delegation which is not
inline with delegation in stateful pce draft which gives
full control to PCE.
 
The use case
described is interesting but I’m afraid that empty ERO was
used for this purpose while there was no discussion at WG
level to achieve consensus for this partial delegation
solution. I would prefer that Juniper used a vendor specific
flag for this behavior rather than using existing objects.
I would prefer
to close the base stateful PCE draft before adding new
features …
 
Partial
delegation may be complex to handle as some people may want
ERO to be controlled by PCC while constraints by PCE and
some other may want the opposite (constraints by PCC and ERO
by PCE) so this requires more discussion.
 
Brgds,
 
Stephane
 

  
From:
Dhruv Dhody [mailto:dhruv.dh...@huawei.com]

Sent: Wednesday, October 05, 2016 06:09
To: Sudhir Cheruathur; LITKOWSKI Stephane
OBS/OINIS; Harish Magganmane; Aissaoui, Mustapha (Nokia
- CA); pce@ietf.org;
draft-ietf-pce-stateful-...@tools.ietf.org
Cc: 'Dhruv Dhody'
Subject: RE: [Pce] Urgent issue with
draft-ietf-pce-stateful-pce : PCE advising PCC about no
path
  

 
Hi
Sudhir/Harish,

 
Thanks
for explaining your motivation but it is not as per the
definition of “delegation”.

What
you are suggesting is a new feature lets call it “partial
delegation”. I hope we can discuss the merit and the
procedures of this in a small separate document away from
this base document. IMHO this document should explain why
partial delegation is needed and especially why PCE would
still like to control how the path is computed at PCC?

 
How
do you/WG feel about taking this approach?

 
Regards,
Dhruv
 
 

  
From: Pce [mailto:pce-boun...@ietf.org]
On Behalf Of Sudhir Cheruathur
Sent: 04 October 2016 23:16
To: stephane.litkow...@orange.com;
Harish Magganmane ;
Aissaoui, Mustapha (Nokia - CA) ;
pce@ietf.org;

  draft-ietf-pce-stateful-...@tools.ietf.org
Subject: Re: [Pce] Urgent issue with
draft-ietf-pce-stateful-pce : PCE advising PCC about no
path
  

 
Stephane/Dhruv/Mustapha,
 
>>I’m
trying to understand what you really want to achieve here.
Or do you want to have PCE updating LSP
parameters/constraints but let the PCC compute path ?
 
We want to
allow changing of other attributes of an LSP (such as
BW/metric), but leave the path computation to the PCC. With
this a PCC now has a choice to do a local CSPF or use IGP
hop-by-hop. This choice can be enforced on the PCC with an
empty ERO and local policy. When we want to drive this same
behavior from the PCE then we could you use a NO-PATH
object.
 
We could
define flags in the NO-PATH object to tell the PCC what to
do when a path is not available. The Nature of Issue is set
to 0 (No path) and flags can be defined to specify the
following 
a) 
  Bring
down the LSP
b) 
  Use
local CSPF
c)  
  Use
IGP based hop-by-hop.
 
Thanks
Redgs
Sudhir C
 
 
 

  From:
  Pce  on behalf of "stephane.litkow...@orange.com" 
Date: Monday, October 3, 2016 at 1:27 AM
  

Re: [Pce] Adoption of draft-pkd-pce-pcep-yang-06

[Julien Meuric]

Hi,

We have consensus to adopt. Authors, please republish under the name 
draft-ietf-pce-pcep-yang-00.


Thanks,

Jon, JP & Julien


Aug. 12, 2016 - Julien Meuric:

Hi all,

During the joint TEAS-MPLS-PCE Yang session in Berlin, we had a clear 
consensus in the room on the interest for the aforementioned I-D. We 
now need to see if the mailing list confirms this consensus. As a 
result, do you think that draft-pkd-pce-pcep-yang-06 is a right 
foundation for a PCE WG document? As usual, comments are very welcome, 
especially if you do not support the adoption.


Thanks,

JP, Jon & 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] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07

[Julien Meuric]

Hi Jon,

Thank you for this "segment routing"-focused feedback.

I fully agree with deferring detailed specification for segment routing 
to another document. The discussed I-D should just:

- be clear on the RSVP-TE case,
- cover a default case (i.e. non-RSVP), with a flexible definition.

This would turn the latest sentence of my proposed paragraph below into:
"For LSPs to be setup by other means, the END-POINTS object SHOULD/MAY 
be omitted; the exact behavior for other types of LSPs will be specified 
in further documents."


Would that address your concern?

Cheers,

Julien


Aug. 16, 2016 - jonathan.hardw...@metaswitch.com:

Hi Julien

During this email, I'm wearing my "segment routing co-author" hat :-)

I agree that END-POINTS is not necessarily congruent with RSVP signalling 
addresses, but I don't agree with the part of the proposed amendment that says 
that this object should not be used for segment-routed LSPs.  As you said, the 
intent of END-POINTS is to give the two points to be interconnected by the LSP. 
 In segment routing, where there is no confusion with RSVP signalling 
addresses, it is useful for the PCC to have this object available.  The PCC 
needs this information in order to use the LSP, and having to derive it from 
the ERO would be more difficult for implementers.

I'd prefer not to say anything about the use of END-POINTS in segment routing 
in this draft.  We can discuss its use in draft-ietf-pce-segment-routing.  Is 
that OK?

Best regards
Jon


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: 29 July 2016 10:16

Dear authors of draft-ietf-pce-pce-initiated-lsp,

Please find below my shepherd's review of the aforementioned I-D.

_Summary_

The document does not need much work to move forward. As discussed with Ina 
during the IETF week, a few items deserve to be highlighted:
- the choice of zero as wildcard PLSP-ID to remove all LSPs initiated by a PCE 
is unsafe;
- the use of the END-POINTS object is misaligned with RFC 5440's definition and 
not suited to SR.

_Detailed Comments_
--
Header
---
- Like with draft-ietf-pce-stateful-pce, adding "Individual Contributor"
after Ed's name helps getting rid of the odd empty line.
--
Abstract
---
- s/provide stateful control/provide active control/
--
Section 1.
---
- s/Path Computation Element Protocol PCEP/Path Computation Element 
communication Protocol (PCEP)/
--
Section 3.
---
- s/provides stateful control/provides active control/
- s/is one of a software-driven/is a software-driven/
- s/is one of dynamically/is dynamically/
- s/is that of demand/is demand/
- s/Operation overview/Operation Overview/
- s/PCE provisioned/PCE-provisioned/
- s/it also generates/it MUST also generate/
- s/PCC also sets/PCC MUST also set/
- s/PCE may update/PCE MAY update/
- s/PCC initiated LSPs/PCC-initiated LSPs/
--
Section 4.
---
- s/PCE provisioned/PCE-provisioned/
--
Section 5.
---
- s/LSP instantiation and deletion/LSP Instantiation and Deletion/
- OLD:
A Path Computation LSP Initiate Message (also referred to as PCInitiate
message) is a PCEP message...
NEW:
A Path Computation LSP Initiate Message is referred to as PCInitiate
message: it is a PCEP message...

- s/and may contain/and MAY contain/
- OLD :
If the SRP object is missing, the PCC MUST send a PCErr with error-type
6 (Mandatory Object missing) and error-value=10 (SRP Object missing) (per 
[I-D.ietf-pce-stateful-pce]. If the LSP object is missing, the PCC MUST send a 
PCErr with error-type 6 (Mandatory Object missing) and
error-value=8 (LSP Object missing) (per [I-D.ietf-pce-stateful-pce]).
NEW:
Missing SRP and LSP objects in PCInitiate MUST trigger the same PCErr 
procedures as specified in [I-D.ietf-pce-stateful-pce] for PCUpd.

- s//[]/  (see discussion below)
- s/5.3. LSP instantiation/5.3. LSP Instantiation/
- s/LSP Initiate Message/PCInitiate message/
- s/results in a PCErr/MUST result in a PCErr/

- The use of the END-POINTS objects has puzzled me for multiple reasons:
   * RFC 5440 defines the object as a pair of IDs allowing to identify the two 
points to be interconnected by the ERO to be filled in, whereas the draft uses 
it to push the IDs of the signaling ends;
   * The signaling source ID to be used should rather be up to the PCC, the 
requirement on pushing it from the PCE is not obvious;
   * The ERO may include some IDs that could be used as default 
source/destination IDs, which also makes the need for a destination ID less 
obvious;
   * To address these, I see 3 options:
1- Giving up the use of a specific object and fully rely on the ERO;
2- Defining new "SignalingRemoteID" types (possibly within the END-POINTS 
object class) to (optionally) convey the info;
3- Rephrase the text to turn the unwanted "redefinition" of the END-POINTS 
object into a wording more consistent with RFC 5440, e.g.:
OLD:
 The

[Pce] Adoption of draft-pkd-pce-pcep-yang-06

[Julien Meuric]

Hi all,

During the joint TEAS-MPLS-PCE Yang session in Berlin, we had a clear 
consensus in the room on the interest for the aforementioned I-D. We now 
need to see if the mailing list confirms this consensus. As a result, do 
you think that draft-pkd-pce-pcep-yang-06 is a right foundation for a 
PCE WG document? As usual, comments are very welcome, especially if you 
do not support the adoption.


Thanks,

JP, Jon & Julien

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

Re: [Pce] Whither Stateless PCE?

[Julien Meuric]

  
  
Hi Ina, hi Stéphane,

I am glad to see this discussion progressing, sorry for
interrupting.

RFC 5440 defines the END-POINTS object, which includes an egress ID.
Do not you think it could be considered to unambiguously convey the
egress destination-attached ID in the PCRpt, without colliding with
the loose ERO case?

Cheers,

Julien


Aug. 12, 2016 -
  

[Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07

[Julien Meuric]

Dear authors of draft-ietf-pce-pce-initiated-lsp,

Please find below my shepherd's review of the aforementioned I-D.

_Summary_

The document does not need much work to move forward. As discussed with 
Ina during the IETF week, a few items deserve to be highlighted:
- the choice of zero as wildcard PLSP-ID to remove all LSPs initiated by 
a PCE is unsafe;
- the use of the END-POINTS object is misaligned with RFC 5440's 
definition and not suited to SR.


_Detailed Comments_
--
Header
---
- Like with draft-ietf-pce-stateful-pce, adding "Individual Contributor" 
after Ed's name helps getting rid of the odd empty line.

--
Abstract
---
- s/provide stateful control/provide active control/
--
Section 1.
---
- s/Path Computation Element Protocol PCEP/Path Computation Element 
communication Protocol (PCEP)/

--
Section 3.
---
- s/provides stateful control/provides active control/
- s/is one of a software-driven/is a software-driven/
- s/is one of dynamically/is dynamically/
- s/is that of demand/is demand/
- s/Operation overview/Operation Overview/
- s/PCE provisioned/PCE-provisioned/
- s/it also generates/it MUST also generate/
- s/PCC also sets/PCC MUST also set/
- s/PCE may update/PCE MAY update/
- s/PCC initiated LSPs/PCC-initiated LSPs/
--
Section 4.
---
- s/PCE provisioned/PCE-provisioned/
--
Section 5.
---
- s/LSP instantiation and deletion/LSP Instantiation and Deletion/
- OLD:
A Path Computation LSP Initiate Message (also referred to as PCInitiate 
message) is a PCEP message...

  NEW:
A Path Computation LSP Initiate Message is referred to as PCInitiate 
message: it is a PCEP message...


- s/and may contain/and MAY contain/
- OLD :
If the SRP object is missing, the PCC MUST send a PCErr with error-type 
6 (Mandatory Object missing) and error-value=10 (SRP Object missing) 
(per [I-D.ietf-pce-stateful-pce]. If the LSP object is missing, the PCC 
MUST send a PCErr with error-type 6 (Mandatory Object missing) and 
error-value=8 (LSP Object missing) (per [I-D.ietf-pce-stateful-pce]).

  NEW:
Missing SRP and LSP objects in PCInitiate MUST trigger the same PCErr 
procedures as specified in [I-D.ietf-pce-stateful-pce] for PCUpd.


- s//[]/  (see discussion below)
- s/5.3. LSP instantiation/5.3. LSP Instantiation/
- s/LSP Initiate Message/PCInitiate message/
- s/results in a PCErr/MUST result in a PCErr/

- The use of the END-POINTS objects has puzzled me for multiple reasons:
 * RFC 5440 defines the object as a pair of IDs allowing to identify 
the two points to be interconnected by the ERO to be filled in, whereas 
the draft uses it to push the IDs of the signaling ends;
 * The signaling source ID to be used should rather be up to the PCC, 
the requirement on pushing it from the PCE is not obvious;
 * The ERO may include some IDs that could be used as default 
source/destination IDs, which also makes the need for a destination ID 
less obvious;

 * To address these, I see 3 options:
  1- Giving up the use of a specific object and fully rely on the ERO;
  2- Defining new "SignalingRemoteID" types (possibly within the 
END-POINTS object class) to (optionally) convey the info;
  3- Rephrase the text to turn the unwanted "redefinition" of the 
END-POINTS object into a wording more consistent with RFC 5440, e.g.:

OLD:
   The END-POINTS Object is mandatory for an instantiation request of an
   RSVP-signaled LSP.  It contains the source and destination addresses
   for provisioning the LSP.  If the END-POINTS Object is missing, the
   PCC MUST send a PCErr message with Error-type=6 (Mandatory Object
   missing) and Error-value=3 (END-POINTS Object missing).
NEW:
   For an instantiation request of an RSVP-signaled LSP, the destination
   address may be needed. The PCC may determine it from a provided object
   (e.g., ERO) or a local decision. Alternatively, the END-POINTS object
   MAY be included to explicitly convey the destination addresses to be
   used in the RSVP-TE signaling. The source address may be either
   specified or left up to the PCC decision using the 0.0.0.0 value. For
   LSPs to be setup by other means (e.g., Segment Routing), the END-POINTS
   object SHOULD be omitted.

 * In case you go for option 2, you still need to be more explicit on 
the non-RSVP case; i.e., the new text should say: "The  MAY 
be included for instantiation request of an RSVP-TE-signaled LSP, and 
SHOULD be omitted otherwise."


- s/echo the SRP-id-number/echo the SRP-ID-number/
- The 2nd paragraph on page 11 ("On succesful completion...") duplicates 
the 2nd one on page 10 ("The PCE MAY include...") and should be dropped 
(or at least the 2nd half of it).

- s/succesful completion/successful completion/
- s/5.3.1. The Create flag/5.3.1. The Create Flag/
- On Figure 3, the "O" would be better in the middle of the 3-bit field.
- Once defined, the phrases "Create flag"/"C Flag"/"C-flag" are 
alternatively used, please pick one and use it everywhere (I personally 
like "C-flag" but "R flag" seems common 

[Pce] Linking Stateful and Stateless Capabilities [Was: Whither Stateless PCE?]

[Julien Meuric]

Hi all,

[New title to help editors of stateful I-Ds to catch up.]

It appears that there is still some shadow on the main stateful I-D. We 
should make sure that any reader has a good understanding of what is 
history behavior and what is not, without assuming incremental 
extensions of IETF protocols is known-enough to guarantee backward 
compatibility.


Mustapha, if you have a couple of clarifying sentences to share, so as 
to address your concerns, that would be valuable.


Thanks,

Julien


Apr. 18, 2016 - mustapha.aissa...@nokia.com:
> Hi Olivier, > > It is one option for sure. In general, 
implementations of stateful > PCE should be able of caching the 
constraints received in the PCReq > message for some period of time to 
give a chance for a potential > follow-up PCRpt message. Even if you set 
the D-flag in the PCReq > message, there is no guarantee that a PCRpt 
will follow and as such a > PCE implementation will have to flush that 
information from its cache > at some point in time. > > > > In addition, 
I think it is worth considering sending the constraints > in a PCRpt 
message in duplicate Metric/LSPA objects with the P-flag > set. This is 
in addition to the same objects containing the > operational values. 
This can be useful in the case where the initial > path was computed by 
the router and it is active and the user is > delegating it. The PCE at 
that point in time will not compute a path > immediately but will save 
the original constraints in the PCRpt > message for the next time it 
needs to update the path. > > > > Regards, > > Mustapha. > > > > 
*From:*EXT Olivier Dugeon [mailto:olivier.dug...@orange.com] *Sent:* > 
Monday, April 18, 2016 8:58 AM > > > > Dear Mustapha, > > You catch a 
good point regarding the original constraints that are > not carry by 
the PCRpt message. Thus, if we used a standard PCReq > message without 
the D-delegate flag set, there is a risk that the PCE > considers this 
request as a stateless one and don't keep track of the > original 
request, and consequently, original constraints. > > So, is it 
preferable to set de D-delegate flag in the PCReq message > to tell the 
PCE to keep in memory the original constraints for > further usage, or, 
is the 'STATEFUL-PCE-CAPABILITY' TLV in Open > message is sufficient for 
the PCE to know that it must keep track of > any requests? I prefer the 
first option as it allows a per request > configuration while the second 
enables the memorization globally for > all requests. > > Regards, > > 
Olivier > > Le 08/04/2016 19:26, Aissaoui, Mustapha (Nokia - CA) a écrit 
: > > Hi Olivier, > > Good summary indeed. I was worried about interop 
testing when I sent > the original email to the list in December 2014. > 
> > > I just wanted to comment on a couple of things: > > > > 1.  
You are correct that the LSP object which has the D-delegate > flag is 
allowed in the PCReq message as per > draft-ietf-pce-stateful-pce. I 
however think it is more appropriate > to do the delegation in the 
subsequent PCRpt message once the LSP > path is programmed by PCC 
following the PCRep message from PCE. This > is because it is at that 
time that the LSP is being synchronized with > the PCE LSP database. > > 
> > 2.  The PCRpt message does not carry the original constraints 
of > the LSP (Bandwidth, Metric, and LSPA objects). It can carry the > 
operational values of the Bandwidth and Metric objects used by the > 
last computed path in the router. So, even if you have a PCE which > 
reacted to the PCRpt message and computed a new path, it will not get > 
the appropriate constraints included. That is why the PCReq/PCRep > 
sequence before delegating the LSP is needed. > > > > Regards, > > 
Mustapha. > > > > *From:*EXT olivier.dug...@orange.com > 
 > [mailto:olivier.dug...@orange.com] 
*Sent:* Friday, April 08, 2016 > 12:29 PM > > > > Hello all, > > IMHO 
the discussion must be split into is 2 different subjects: > > 1/ PCInit 
message could be seen as an independent message compared to > other 
PCReq/PCRep, PCRpt and PCUp. Indeed, the PCE uses the PCInit > message 
after a request that comes from another interface (e.g. a > RestConf 
API) instead of PCReq that comes from the router itself > through PCEP. 
In fact, when you configure a tunnel on the router, > only the path 
computation part is requested to the PCE. Complements > of tunnel 
configuration still remain in the router configuration. In > case of 
PCInit, all information must be provided to the router. This > could be 
for example the traffic steering. So, IMHO, it is normal > that the 
PCInit message evolves through extensions different from the > other 
PCEP messages, and in particular PCReq, as it is not triggered > by the 
same entity, i.e. an external component instead the PCC router > itself. 
> > 2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 
> will continue to be mandatory for stateful both passive and 

Re: [Pce] Whither Stateless PCE?

[Julien Meuric]

Hi Adrian,

Based on the evolution of this thread, it looks like it leaves us with 
the following guidelines:

- The case by case basis looks reasonable and should prevail;
- Extensions should focus on what is (eventually) useful;
- The scope of each work should be explicitly mentioned in I-Ds.

I hope this is an acceptable answer to your question.

Regards,

Julien


Apr. 07, 2016 - adr...@olddog.co.uk:
> I think you are probably right, Dhruv. > > > > But referencing the 
ways in which customers deploy may be a little > limiting. > > To say 
PCE is widely deployed (even after all these years) may be an > 
exaggeration. > > Although we do have some clues about what is currently 
being pushed > for deployment. > > > > I think you have mainly grasped 
my point, however. We need to > understand which extensions are 
definitely only needed in one mode or > another, and which should be 
done in all modes (either because they > are needed or because we don't 
know). > > > > OTOH, I suppose TLVs are just TLVs. Once you specified 
the TLV it is > not rocket science to include it in a message. In fact, 
it is > probably one line of text to include it and only a short 
paragraph to > describe additional processing in other modes once you 
have described > how it is used in one mode. > > > > Where does that 
leave us? > > > > Adrian > > > > *From:*dhruvdh...@gmail.com 
[mailto:dhruvdh...@gmail.com] *On Behalf > Of *Dhruv Dhody *Sent:* 06 
April 2016 23:07 > > > > Hi Adrian, > > > > Even in the brave new world 
of Stateful PCE, PCReq and PCRep messages > do play a role in the 
passive stateful PCE mode. PCReq/PCRep also > play a crucial role in the 
inter-domain and inter-layer context in > the new proposal like stateful 
H-PCE. > > > > At the same time mandating that every extension (say SFC) 
must also > be specified in a stateless manner when no customer deploy 
in such a > way, might be overkill. > > > > Perhaps we need to look at 
it case by case! > > > > Dhruv > > > > On Wed, Apr 6, 2016 at 4:00 PM, 
Adrian Farrel  > 
wrote: > > Once upon a time, in a working group far, far away, PCE was 
basically > stateless. PCE acted in response to questions asked by PCCs. 
> > These days, everyone is excited by stateful PCEs and there is a lot 
> of initiation (of LSPs or of control of LSPs). > > In the jabber room 
during today's meeting Ravi noted that not a lot > of the new drafts 
(maybe none of them) talk about PCReq messages. > This raises the 
question in our minds as to whether stateless PCE is > obsolete. > > If 
(and only if) this mode of PCE usage has gone out of fashion, we > 
*might* consider cleaning up the protocol and architecture so that we > 
don't need to make protocol extensions to PCReq and PCRep messages > 
when we make extensions to PCInit messages. > > Thoughts? > > Adrian >


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

[Pce] Fwd: WG Action: Rechartered IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)

[Julien Meuric]

F.Y.I.: the 6tisch WG has just been rechartered, "PCE" is explicitly 
mentioned.


Julien


 Message transféré 
Date : Fri, 4 Mar 2016 08:38:31 -0800
De : The IESG 

The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG in the Internet
Area of the IETF has been rechartered. For additional information, please
contact the Area Directors or the WG Chairs.

IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
---
Current status: Active WG

Chairs:
  Pascal Thubert 
  Thomas Watteyne 

Assigned Area Director:
  Brian Haberman 

Internet Area Directors:
  Brian Haberman 
  Terry Manderson 

Mailing list:
  Address: 6ti...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/6tisch
  Archive: https://mailarchive.ietf.org/arch/browse/6tisch/

Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".

Background/Introduction:


Low-power and Lossy Networks (LLNs) interconnect a possibly large number
of resource-constrained nodes to form a wireless mesh network. The
6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at
various layers of the protocol stack, including an IPv6 adaptation
layer, a routing protocol and a web transfer protocol. This protocol
stack has been used with IEEE802.15.4 low-power radios.

The Timeslotted Channel Hopping (TSCH) mode was introduced in 2012 as an
amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4
standard. TSCH is the emerging standard for industrial automation and
process control LLNs, with a direct inheritance from WirelessHART and
ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the
further adoption of IPv6 in industrial standards and the convergence of
Operational Technology (OT) with Information Technology (IT).

The nodes in a IEEE802.15.4 TSCH network communicate by following a
Time Division Multiple Access (TDMA) schedule. A timeslot in this
schedule provides a unit of bandwidth that is allocated for
communication between neighbor nodes. The allocation can be programmed
such that the predictable transmission pattern matches the traffic. This
avoids idle listening, and extends battery lifetime for constrained
nodes. Channel-hopping improves reliability in the presence of narrow-
band interference and multi-path fading.

These techniques enable a new range of use cases for LLNs, including:
- Control loops in a wireless process control network, in which high
reliability and a fully deterministic behavior are required.
- Service Provider networks transporting data from different independent
clients, and for which an operator needs flow isolation and traffic
shaping.
- Networks comprising energy harvesting nodes, which require an
extremely low and predictable average power consumption.

IEEE802.15.4 only defines the link-layer mechanisms. It does not define
how the network communication schedule is built and matched to the
traffic requirements of the network.

Description of Working Group:
-

The Working Group will focus on enabling IPv6 over the TSCH mode of the
IEEE802.15.4 standard. The extent of the problem space for the WG is
one or more LLNs, possibly federated through a common backbone link
via one or more LLN Border Routers (LBRs). The WG will rely on, and if
necessary extend, existing mechanisms for authenticating LBRs.

Initially, the WG has limited its scope to distributed routing over a
static schedule using the Routing Protocol for LLNs (RPL) on the
resulting network. This new charter allows for the dynamic allocation of
cells and their exchange between adjacent peers to accommodate the
available bandwidth to the variations of throughput in IP traffic.

The WG will continue working on securing the join process and making
that fit within the constraints of high latency, low throughput and
small frame sizes that characterize IEEE802.15.4 TSCH.

Additionally, IEEE802.15.4 TSCH being a deterministic MAC, it is
envisioned that 6TiSCH will benefit from the work of DetNet WG to
establish the so-called deterministic tracks. The group will define the
objects and methods that need to be configured, and provide the
associated requirements to DetNet.

The WG will interface with other appropriate groups in the IETF
Internet, Operations and Management, Routing and Security areas.

Work Items:
---

The group will:

- Produce a specification of the 6top sublayer that describes the
protocol for neighbor nodes to negotiate adding/removing cells. This
work will leverage cross participation from IEEE members including the
IEEE 6TiSCH Interest Group (IG 6T) to define protocol elements and
associated frame formats.

- Produce a specification for a default 6top Scheduling 

Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11

[Julien Meuric]

Hi Ina,

Thank you for publishing the update. It looks like most comments are 
incorporated. Just a few remain open, see [JM] below.


Cheers,

Julien


Dec. 03, 2015 - inami...@google.com:
All the changes discussed in this thread have been incorporated in 
version 13 published yesterday


https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-13

Thank you,

Ina





- Avoiding "positive acknowledgements for properly received
synchronization messages" has scalability benefits in normal
situations, but the PCC is blind and may keep on sending
PCRpt to
dead processes behind up PCEP sessions. Have you consider
acknowledgement, possibly using a compression mechanism
like the
one defined later in the I-D?

### XXX Pending

%%%  No, we did not think we needed positive acks because we are using 
a TCP session (guaranteed delivery all the way to the PCE).


[JM] Yes, leaving the man in the middle case apart, we almost agree on 
that, but I believe it is not enough. Even if PCEP and TCP stacks are 
OK, the PCC still cannot know if the PCRpt has been processed by the PCE 
and/or properly stored in its DB. E.g., how can the PCC distinguish 
between the expected processing and a PCE considering some message as 
wrongly formed while not supporting the relevant error message?






  - In section 5.5.3, assuming an LSP was delegated, does the
reception by the PCC of a non empty LSP Update Request with a
Delegate Flag to 0 trigger an error?

   ### XXX Pending

%%% No, this is a delegation return. I cleaned up the text, see below.

In order to keep a delegation, a PCE MUST set the Delegate flag to 1
   on each LSP Update Request sent to the PCC.  A PCE that no longer
   wishes to update an LSP's parameters SHOULD return the LSP delegation
   back to the PCC by sending an empty LSP Update Request which has the
   Delegate flag set to 0.  If a PCC receives a non-empty LSP Update
   Request with the Delegate flag set to 0, it MUST treat this as a
   delegation return.

[JM] That is quite difficult to fully understand. Delegation returns <=> 
flag set to 0 seems clear. But why are "empty" associated to "SHOULD" 
and "non-empty" to MUST? Rewording is required to make sure all 
sub-cases are covered.







- In section 5.6.2, in case of new LSP, the very first message
sent by the PCC aims at getting a path. This is clearly
the role
of a PCReq message, and the I-D extends it to support the LSP
object including the delegation flag (section 7.3). However,
Figure 8 treats a new LSP the same way as reporting an
existing
LSP, i.e., using a PCRpt message. In this case, there is an
overlap between PCReq and PCRpt, which MUST be resolved
because
interoperability is at stake. Documenting the delegation
of a new
LSP deserves some new text and possibly figure, the
overlapping
specification of the PCRpt should be explicitly precluded.

### This is historical confusion in the figure, from the time
when initiation was rolled up in the same document. I modified
the figure so it is clear this is for updating parameters only.

 [JM] Seems addressed. Just to be confirmed when published and to
confront with draft-ietf-pce-pce-initiated-lsp.

[JM] Reading the new section 6.1, the /ERO being 
mandatory, the case of an empty ERO should be documented. I believe 
adding an error code to handle it would be enough.


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

Re: [Pce] Poll on Adoption of draft-minei-pce-association-group-03

[Julien Meuric]

Hi all,

Support looks clear. Authors, please publish the latest version as 
draft-ietf-pce-association-group-00.


Thanks,

Julien


Nov. 04, 2015 - Julien Meuric:

Dear all,

Following our discussion during the WG meeting yesterday, do you 
support the adoption of draft-minei-pce-association-group-03 as a 
starting point for a new PCE WG item? If not, please motivate your 
answer.


In any case, comments are welcome.

Regards,

Jon, JP & 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] PCE WG Last Call - draft-ietf-pce-pceps-04

[Julien Meuric]

Hi Dhruv,

If you expect some updates after a review from the Security Directorate, 
then the sooner the better. If you feel it useful, we will proceed when 
your next revision is published.


Thanks for being proactive here,

Julien


Nov. 19, 2015 - dhruv.dh...@huawei.com:

Hi Julien,

We have the update ready to go.

Quoting from Tom's mail -


So I value the early intervention of the
Security Directorate to try and fix such
issues sooner, and so cheaper, rather than later.


We were wondering if it would be worthwhile (and allowed by the process) to 
request for an early Sec-Dir review while the control is still with the WG?

Regards,
Dhruv



-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: 19 November 2015 14:56

Hola Diego,

The WG LC was started for a 2-week period: you can consider it finished.

Finished or not, you are expected to resolve all the received comments and
publish an update accordingly, so as to have the I-D ready to be sent to the
IESG. Feel free to proceed as soon as you are able to.

Cheers,

Julien


Nov. 18, 2015 - diego.r.lo...@telefonica.com:


And let me insist that I'd directly ask the UTA WG about this. My only
question is about procedure: shall we wait till we finish the last
call period? Shall we perform it as part of the last call process?
What do our chairs think?


___
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] PCE WG Last Call - draft-ietf-pce-pceps-04

[Julien Meuric]

Hola Diego,

The WG LC was started for a 2-week period: you can consider it finished.

Finished or not, you are expected to resolve all the received comments 
and publish an update accordingly, so as to have the I-D ready to be 
sent to the IESG. Feel free to proceed as soon as you are able to.


Cheers,

Julien


Nov. 18, 2015 - diego.r.lo...@telefonica.com:


And let me insist that I’d directly ask the UTA WG about this. My only 
question is about procedure: shall we wait till we finish the last 
call period? Shall we perform it as part of the last call process? 
What do our chairs think?


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

Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11

[Julien Meuric]

Hi Ina,

Following our fruitful discussing in Yokohama, please find [JM]'s note 
below. Just a few items are pending, I hope you will soon find an 
agreement with your co-authors.


WG, if you disagree with the proposed change about discovery bit 
allocation below, please let us know.


Julien


Oct. 26, 2015 - inami...@google.com:

Julien,

Thank you for the detailed review, please find answers inline below 
###.  I have incorporated the overwhelming majority of the comments, 
explained the reason for not incorporating a couple of them, and am 
still working with the co-authors on a couple of items marked 
"pending", which we will close on shortly.


Two questions and one ask
1. Forward references to SRP object and SRP-ID - there are several in 
the comments, though the relevant section is always mentioned. How 
should such forward references be addressed?
[JM] A simple way is to add the acronym and its expansion into the 
terminology section, and optionally the forward reference.


2. Section 7 - s/defined in this document/defined in that 
(aforementioned) document/
The comment was not clear to me. The intention is for the flags to be 
set as explained for the new objects we are defining here, can you 
clarify the comment?
[JM] Just suggesting a rewording, but my proposal was not clear either; 
"this current I-D" may be enough to clear the ambiguity.


3. Can you please review the comments that were not incorporated and 
let us know if you agree?

[JM] See below.


Thank you,

Ina

On Fri, Oct 16, 2015 at 7:40 AM, Julien Meuric 
<julien.meu...@orange.com> wrote:




- s/Active Stateful PCE: is an extension/Active Stateful PCE: an
extension/

 ### Replaced as "an Active Stateful PCE that may issue 
recommendations...



[JM] Guessing you actually meant "a Stateful PCE that may...", it is OK.




- OLD
Redelegation Timeout Interval: when a PCEP session is terminated,
a PCC waits for this time period before revoking LSP delegation to
a PCE and attempting to redelegate LSPs associated with the
terminated PCEP session to an alternate PCE.
  NEW
Redelegation Timeout Interval: the period of time a PCE waits for,
when a PCEP session is terminated, before revoking LSP delegation
to a PCE and attempting to redelegate LSPs associated with the
terminated PCEP session to an alternate PCE.

### Done


- OLD
State Timeout Interval: when a PCEP session is terminated, a PCC
waits for this time period before flushing LSP state associated
with that PCEP session and reverting to operator-defined default
parameters or behaviors.
  NEW
State Timeout Interval: the period of time a PCE waits for, when a
PCEP session is terminated, before flushing LSP state associated
with that PCEP session and reverting to operator-defined default
parameters or behaviors.

### Done
[JM] I hope you caught my (double) typo: I was only trying to rephrase, 
the waiting party remaining the PCC.





- Section 3.1.3 includes 2 paragraphs "Scale and Performance":
they should either be merged, or the old text version should be
dropped.

### Done, new text below:
  o  Scale & Performance: configuration operations often have
   transactional semantics which are typically heavyweight and often
   require processing of additional configuration portions beyond the
   state being directly acted upon, with corresponding cost in CPU
   cycles, negatively impacting both PCC stability LSP update rate
   capacity.

[JM] Looks fine to me.




- The reference to draft-sivabalan-pce-disco-stateful makes the
reader wonder why is is not part of draft-ietf-pce-stateful-pce
itself. Besides, Table 1 also mentions IS-IS and OSPF
PCE-CAP-FLAGS sub-TLV, only the allocation section seems to be
missing here. Would you talk to the authors (some being common to
both I-Ds) of the former to consider using their material as a
contribution? A separate document is quite an overhead for
allocating 2 bits.


### I don't think discovery should be part of the base draft. Several 
reasons: a) 5440 does not include discovery, b) the base spec is 
already quite large, we want to keep only the core function and  c) 
the discovery draft is expired. I cleaned up table 1 and added the 
following text instead of the reference to the draft:

Old text
[I-D.sivabalan-pce-disco-stateful] defines the extensions needed 
tosupport autodiscovery of stateful PCEs when using OSPF ([RFC5088]) 
or IS-IS ([RFC5089]) for PCE discovery.

New text
Similarly to [RFC5440], no assumption is made about the discovery 
method used by a PCC to discover a set of PCEs (e.g., via static 
configuration or dynamic discovery) and on the algorithm used to 
select a PCE. Extensions needed to support autodiscovery will be 
defined in a separate document.
[JM] Along with RFC 5557 and 6006, including discovery bit allo

Re: [Pce] Initial version for liaison text: New Liaison Statement, "Achieving Packet Network Optimization using DWDM Interfaces"

[Julien Meuric]

  
  
Hi Daniele,

I am sorry, but:
- the received document is not clear to me and deserves
clarification to be properly commented;
- I am strongly surprised by the deep change with respect to the
previous version of the response shared before;
- the proposed response does not match the scope of the liaised
document; e.g., quoting section 3.1: "the reference point Db (see
Figure 2), can use underlying technology based on IEEE 802.3
Ethernet [2] or ITU-T  G.959.1  OTN", then why do we point to I-Ds
related to WDM interfaces?

As a result, I am very confused between the liaison and the proposed
response...

Cheers,

Julien


Nov. 10, 2015 -
  daniele.ceccare...@ericsson.com:


  
  
  
  
Hi CCAMP, TEAS
and PCE,
 
Please find
below a slightly revised text for the reply to the BBF
liaison. We took the commitment to send this by mid of this
week, please let us know if you have any concern with the
text.
 
“The TEAS, PCE and CCAMP working groups
  would like to thank you for informing of us of the BBF effort
  on packet-optical networks and sending the document to us for
  review.
 
Reviewing the requirements proposed in the
  document, we noted the reference to IETF RFCs on GMPLS and PCE
  for satisfying the control requirements. As you progress your
  work, please inform us if you identify any gaps in order to
  satisfy these requirements.
 
For your information, IETF CCAMP is working
  on an update regarding the management and control of DWDM
  optical interface parameters and GMPLS protocols (please refer
  to draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk) which might be
  relevant to your project. This draft is still an individual
  contribution but it was indicated as “candidate for WG
  adoption” at the last meeting. The document has a set of
  companion documents defining extensions for SNMP
  (draft-galikunze-ccamp-dwdm-if-snmp-mib), LMP
  (draft-dharinigert-ccamp-dwdm-if-lmp) and YANG data models ( 
https://tools.ietf.org/html/draft-dharini-netmod-dwdm-if-yang-00
  ). These documents are still in the individual contribution
  status and will be evaluated for WG adoption after the
  framework.
Feedback from the BBF would be highly
  appreciated and can be provided on the CCAMP mailing list
  without the need for a formal liaison.”
 
 
Thanks
Daniele &
Fatai
 

  

  From:
  Teas [mailto:teas-boun...@ietf.org]
  On Behalf Of Daniele Ceccarelli
  Sent: domenica 1 novembre 2015 04:27
  To: Zhenghaomian; 'cc...@ietf.org';
  pce@ietf.org; TEAS WG
  Subject: Re: [Teas] Initial version for liaison
  text //答复:
  CALL FOR VOLUNTEER - New Liaison Statement, "Achieving
  Packet Network Optimization using DWDM Interfaces"

  
   
  Hi Haomian, all,
   
  Thanks for starting putting together
the reply. Please find some updated proposals from my side.
   
  ===
  The working groups in IETF routing
area would like to thank you for sending this liaison. We
much appreciate BBF on the effort of packet over optical,
and sending the document to IETF CCAMP, TEAS and PCE WGs for
review. This project defines a set of control plane
requirements that the Physically Separated Model should be
satisfied. We have some questions and comments:

   
  Questions:
  
•
It is not clear to us
how the communication between the packet layer and the
optical layer occurs. E.g. control channels, signaling and
so on.
  
•
We would like to see
some more details on the management aspects between the
packet domain and the optical domain.
  Comments:
  
•
When referring to PCE
and related issues, e.g., in [R-26] and [R-27], it seems
only stateless PCE (RFC4655) and corresponding PCEP
(RFC5520) are included in the current version. As IETF PCE
working group is investigating on stateful PCE, PCE
Initiation and PCE as a Central Controller, which are
planned to be published in the future, it is better to

Re: [Pce] Comments on draft-minei-pce-association-group

[Julien Meuric]

Hi all,

Nov. 05, 2015 - lber...@labn.net:

Loa = Lou = me


Does it mean we've all been abused by this fake beard for years?!

Anyway, than you for working together during adoption polling: that is a 
strong move to build the consensus we are trying to judge there.


Regards,

Julien

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

[Pce] Poll on Adoption of draft-minei-pce-association-group-03

[Julien Meuric]

Dear all,

Following our discussion during the WG meeting yesterday, do you support 
the adoption of draft-minei-pce-association-group-03 as a starting point 
for a new PCE WG item? If not, please motivate your answer.


In any case, comments are welcome.

Regards,

Jon, JP & Julien

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

Re: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-05.txt

[Julien Meuric]

  
  
Hi Ina,

Please note that there are pending questions on this I-D:
https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE

Thanks,

Julien


Oct. 19, 2015 - inami...@google.com:


  
  This is just a version refresh, to prevent the
draft from expiring, no changes were made to the draft. 


  
  
On Mon, Oct 19, 2015 at 9:56 AM, 
  wrote:
  
A New Internet-Draft is available from the on-line
Internet-Drafts directories.
 This draft is a work item of the Path Computation Element
Working Group of the IETF.

        Title           : PCEP Extensions for PCE-initiated
LSP Setup in a Stateful PCE Model
        Authors         : Edward Crabbe
                          Ina Minei
                          Siva Sivabalan
                          Robert Varga
        Filename        :
draft-ietf-pce-pce-initiated-lsp-05.txt
        Pages           : 17
        Date            : 2015-10-19

Abstract:
   The Path Computation Element Communication Protocol
(PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to
perform path
   computations in response to Path Computation Clients
(PCCs) requests.

   The extensions for stateful PCE provide stateful control
of
   Multiprotocol Label Switching (MPLS) Traffic Engineering
Label
   Switched Paths (TE LSP) via PCEP, for a model where the
PCC delegates
   control over one or more locally configured LSPs to the
PCE.  This
   document describes the creation and deletion of
PCE-initiated LSPs
   under the stateful PCE model.



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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-05

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


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
  


  
  
  
  
  ___
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] Building the PCE Agenda for IETF 94

[Julien Meuric]

Dear all,

The PCE agenda is on line 
(https://www.ietf.org/proceedings/94/agenda/agenda-94-pce). If you have 
a slot, please send your slides to the chairs and secretary by Sunday, 
noting that your allocated duration may differ from your original request.


Regards,

Jon, JP & Julien


Oct. 12, 2015 - Julien Meuric:

Hi all,

FYI, the PCE session is now scheduled on Tuesday, from 5:10 to 6:40 
pm, right before the social event.


By the way, Yokohama meeting is number 94: sorry for the typo in the 
previous e-mail.


Regards,

Jon, JP & Julien


Oct. 05, 2015 - julien.meu...@orange.com:

Dear PCE WG,

The IETF preliminary agenda is available 
(https://datatracker.ietf.org/meeting/94/agenda.html). The PCE 
session is _tentatively_ scheduled on Monday from 3:20 to 4:50 pm. 
Supposing you have issues that _really_ require a slot to progress, 
please send a request to the chairs and secretary, including:

- the topic to discuss,
- the expected duration,
- the name of the presenter,
- the rationale for requesting some face to face time, as opposed to 
using the mailing list, i.e., the output you expect from your slot.


Best regards,

JP & 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] Query on Usage of LSP Identifier TLV in SR

[Julien Meuric]

Hi Girish,

Due to the very different levels of maturity between stateful-pce and 
MBB I-Ds, we do not see them merging. MBB I-D was very briefly discussed 
on the list a while ago, we do not know what the plans of the authors are...


Regards,

Julien


Oct. 12, 2015 - girish...@gmail.com:


piggy backing on Dhruv email ...

During PCUpdate for SR LSP -  MBB process mentioned in 
draft-tanaka-pce-stateful-pce-mbb applicable? The MBB draft has 
expired, will it be incorporated in stateful-pce draft?


Thanks,
Girish

On Sun, Oct 11, 2015 at 10:58 PM, Dhruv Dhody > wrote:


Hi Authors,

In the stateful PCE draft [1], it says –

The LSP Identifiers TLV MUST be included in the LSP object in PCRpt

messages for RSVP-signaled LSPs.

The SR draft [2] did not mention anything about LSP Identifier TLV.

And in implementations that I am aware of, SR-TE LSP still uses
the LSP-Identifier TLV. Is that correct? (I personally think so!!)

If yes, do you think there is a need to update –

-[1] to say all LSPs (and not just RSVP-signaled).

-Or [2] to say that LSP-Identifier TLV are also applicable to SR
and MUST be included.

Thanks!

Dhruv

[1]
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-11#section-7.3.1

[2] http://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/


___
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


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

Re: [Pce] Building the PCE Agenda for IETF 94

[Julien Meuric]

Hi all,

FYI, the PCE session is now scheduled on Tuesday, from 5:10 to 6:40 pm, 
right before the social event.


By the way, Yokohama meeting is number 94: sorry for the typo in the 
previous e-mail.


Regards,

Jon, JP & Julien


Oct. 05, 2015 - julien.meu...@orange.com:

Dear PCE WG,

The IETF preliminary agenda is available 
(https://datatracker.ietf.org/meeting/94/agenda.html). The PCE session 
is _tentatively_ scheduled on Monday from 3:20 to 4:50 pm. Supposing 
you have issues that _really_ require a slot to progress, please send 
a request to the chairs and secretary, including:

- the topic to discuss,
- the expected duration,
- the name of the presenter,
- the rationale for requesting some face to face time, as opposed to 
using the mailing list, i.e., the output you expect from your slot.


Best regards,

JP & Julien


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