[Pce] Publication has been requested for draft-ietf-pce-iana-update-02

[Julien Meuric via Datatracker]

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


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

[Pce] Shepherd Review of draft-ietf-pce-iana-update-02

[julien . meuric]

Hi authors,

I've reviewed draft-ietf-pce-iana-update-02. The I-D is clear and ready 
to move forward. I particularly liked:
- the full expansion of the PCEP acronym in the title, including 
"Communication", while quoting the registry name as is;
- the care taken on not overriding the experimental range of the 
"Generalized Endpoint Types" registry, which will avoid an additional 
request/response with the IANA;
- the appendixes, keeping track of the WG's discussion, which is useful 
for the shepherd. :-)


Thanks,

Julien




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

[Pce] Adoption Poll for draft-peng-pce-stateful-pce-autobw-update

[julien . meuric]

Hi all,

This is an adoption poll for draft-peng-pce-stateful-pce-autobw-update. 
Do you believe that this document [1] is a right foundation for a PCE WG 
item?
Please use the PCE mailing list to express your support or the reasons 
why you may be opposed to its adoption.


Thank you,

Julien

---
[1] 
https://datatracker.ietf.org/doc/html/draft-peng-pce-stateful-pce-autobw-update




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

[Pce] Re: WG Last Call for draft-ietf-pce-iana-update

[julien . meuric]

Hi PCE'rs,

This WGLC has ended. Thank you to the WG for the useful feedback; thank 
you to the authors for resolving the comments and updating the I-D 
accordingly. I'll now proceed with the shepherd review.


Thanks,

Julien


On 06/09/2024 14:23:58 julien.meu...@orange.com wrote:

Hi all,

Since we have consensus, let's move forward with this simple fix to 
[1], as agreed with the IESG. This message starts a 2-week WG last 
call for draft-ietf-pce-iana-update-01 [2]. Please share your support 
or comments on the PCE mailing list by Friday September 20.


Thank you,

Julien


[1] https://www.rfc-editor.org/cluster_info.php?cid=C519
[2] https://datatracker.ietf.org/doc/html/draft-ietf-pce-iana-update-01



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

[Pce] WG Last Call for draft-ietf-pce-iana-update

[julien . meuric]

Hi all,

Since we have consensus, let's move forward with this simple fix to [1], 
as agreed with the IESG. This message starts a 2-week WG last call for 
draft-ietf-pce-iana-update-01 [2]. Please share your support or comments 
on the PCE mailing list by Friday September 20.


Thank you,

Julien


[1] https://www.rfc-editor.org/cluster_info.php?cid=C519
[2] https://datatracker.ietf.org/doc/html/draft-ietf-pce-iana-update-01



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

[Pce] Re: Adoption Poll of draft-dhody-pce-iana-update

[julien . meuric]

Hi all,

We have clear support and no objection on adopting this small I-D: it is 
now a PCE WG item.


@Authors: please re-submit the draft as draft-ietf-pce-iana-update-00.

@Authors of draft-farrel-pce-experimental-errors: please talk to the 
authors of the aforementioned I-D to consider adding your proposal as a 
contribution into this new WG effort.


Thank you,

Julien


Le 30/07/2024 à 10:36, julien.meu...@orange.com a écrit :

Hi all,

In his review of the "native IP" draft, John suggested to consider 
adjusting to "IETF Review" the allocation policy of some of the PCEP 
registries currently using "Standards Action". Dhruv has submitted 
draft-dhody-pce-iana-update to quickly resolve this concern and bring 
higher consistency among PCEP registries.


As a result, does the WG support the adoption of 
draft-dhody-pce-iana-update [1] as a WG item? Please, share your 
feedback using the PCE mailing list and include your rationale in case 
you're opposed.


Thanks,

Julien


[1] https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/


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

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[julien . meuric]

Hi Samuel.

Assuming we get consensus on option 1, I believe it does make sense to 
add a sentence in the I-D leaving explicitly the door open for a further 
extension.


Thanks,

Julien


On 31/07/2024 09:41, Samuel Sidor (ssidor) wrote:
Does it make sense to explicitly mentioned in the draft that updating 
ranges dynamically was considered, but is considered out of scope and 
can be introduced later as separate draft if frequent range updates 
are needed?




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

[Pce] Adoption Poll of draft-dhody-pce-iana-update

[julien . meuric]

Hi all,

In his review of the "native IP" draft, John suggested to consider 
adjusting to "IETF Review" the allocation policy of some of the PCEP 
registries currently using "Standards Action". Dhruv has submitted 
draft-dhody-pce-iana-update to quickly resolve this concern and bring 
higher consistency among PCEP registries.


As a result, does the WG support the adoption of 
draft-dhody-pce-iana-update [1] as a WG item? Please, share your 
feedback using the PCE mailing list and include your rationale in case 
you're opposed.


Thanks,

Julien


[1] https://datatracker.ietf.org/doc/draft-dhody-pce-iana-update/


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
To unsubscribe send an email to pce-le...@ietf.org

[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&url2=draft-ietf-pce-pcep-yang-24&difftype=--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&url2=draft-ietf-pce-pceps-tls13-02&difftype=--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&url2=draft-ietf-pce-pceps-tls13-02&difftype=--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

[Pce] IPR Check on draft-ietf-pce-association-group

[Julien Meuric]

Dear authors of draft-ietf-pce-association-group,

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-association-group 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

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

[Julien Meuric]

atly, 
  
  
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

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

[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

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 


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 infe

[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
Pce@ietf.or

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?
>>
>&

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 LSP

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] Mirja Kühlewind's No Objection on draft-ietf-pce-pce-initiated-lsp-10: (with COMMENT)

[Julien Meuric]

Hi all,

We may add on top of the reasons below the strong impact PCE-initiation
has from the implementation's perspective (which is somehow linked to
the first 2 items).
Up to I-D.ietf-pce-stateful-pce, it was all about configuration on PCCs,
just allowing PCEs to trigger actions. I-D.ietf-pce-pce-initiated-lsp is
a significant change: it enables PCEs to create on PCCs states which are
not part of operator-specified PCCs' configuration. As a result, there
has already been some commercial implementations at the stage described
by the 2nd item.

My 2 cents,

Julien


Oct. 04, 2017 - jonathan.hardw...@metaswitch.com:
> 1) I'm wondering why this spec is not part of I-D.ietf-pce-stateful-pce as it 
> is also not published yet...?
> 
> Jon> It has been published now.  The main reasons were
> - it took longer for PCE-initiated LSPs to be accepted into the PCE WG, and 
> the authors did not want to hold up work on the base draft
> - I-D.ietf-pce-stateful-pce was a self-contained set of function and it was 
> envisioned that there was a class of device that would not implement the LSP 
> initiation extensions
> - I-D.ietf-pce-stateful-pce was already fairly long and complex, and merging 
> them would have been an editing / reviewing headache.

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

Re: [Pce] Best Wishes for the future of PCE WG !

[Julien Meuric]

Goodbye JP! Thank you for everything (the list's too long). I look
forward to working with you again.

Cheers,

Julien


Aug. 22, 2017 - jvass...@cisco.com:
> Dear WG,
>
> Almost 12 years since we started the PCE WG ! More than 30 RFCs, many
> re-charterings, closely working with several other WGs (MPLS, CCAMP,
> OSPF, ISIS, …) and of course _many implementations and deployments in
> the field applying the PCE architecture to several areas _!
>
> As you might have noticed I have been fairly silent for the past two
> years, driving several quite hectic projects related to Machine
> Learning for the network (Security, Wireless, IoT, …) not involving
> too much of standardization work (yet). As discussed a few times, the
> PCE may also play a great role in ML/AI for central global
> optimization :-) 
>
> As agreed with our AD Deborah I have completed a transition phase, and
> it is a great time for me to step down as PCE co-chair.
>
> I would like to warmly thank my friend Adrian whom I started the PCE
> WG with in 2005 and many years of close collaboration, Julien Meuric
> who has been a terrific co-chair, and Jonathan who stepped up as new
> co-chair at light speed, not forgetting Dan for years as secretary and
> now Dhruv. 
>
> See you all soon !
>
> Cheers,
>
> JP.
>
>

___
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

Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

[Julien Meuric]

  
  
Hi,

I agree that capability bitmap with optional capability-specific
sub-TLVs would be the way to go from scratch. However the
SR-PCE-CAPABILITY already has an early allocated codepoint, and RFC
7120 says that "if there is a change, implementations based on the
earlier and later specifications must be seamlessly interoperable."
As a result, it seems to me that adding this new format may require
that the I-D keeps documenting an optional SR-PCE-CAPABILITY TLV for
legacy reasons.

Cheers,

Julien


Jul. 25, 2017 -
  jonathan.hardw...@metaswitch.com:


  
  
  
  
I agree that
allowing optional sub-TLVs is a good thing.  However, this
strongly suggests that SR-PCE-CAPABILITY should become a
sub-TLV, which is a non-backwards compatible change.  So, we
are back to my original question.
 
Implementers –
any views?
 
Cheers
Jon
 
 

  
From: Adrian
Farrel [mailto:adr...@olddog.co.uk]

Sent: 24 July 2017 19:51

  

 
Yes to that,
Jon. But what happens when the next thing comes along?
 
Since sub-TLVs
can be present, I would suggest to use a Setup-Type TLV with
a bit map as I previously described in my email, and add
optional sub-TLVs dependent on the bits that are set.
 
Isn't that the
best of both worlds?
 
Adrian
 

  

  From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
  
  Sent: 24 July 2017 09:15


  
   
  Adrian,
   
  The
  SR-PCE-CAPABILITY TLV is more than just a Boolean value -
  it also contains information about the maximum SID depth. 
  However, I like your idea and I think that it gives us a
  better way to do this without breaking backwards
  compatibility with existing SR implementations.
   
  Suppose we
  introduce a setup-type TLV into the OPEN object as you
  propose, and assign a bit to each setup type.
  If the TLV is
  absent, then RSVP-TE is supported.
  If the TLV is
  absent and the SR-PCE-CAPABILITY TLV is present, then
  RSVP-TE and SR are supported.  This retains backwards
  compatibility with existing SR implementations.
  If the TLV is
  present, then the bits indicate which setup types are
  supported.
   
  We would
  modify the LSP setup type draft to say that
  implementations supporting path setup types other than
  RSVP-TE SHOULD include the setup-type TLV.
   
  It’s not
  exactly beautiful, but it’s not as ugly as
  RSVP-TE-NON-SUPPORT.
   
  Cheers
  Jon
   
   
  

  From:
  Adrian Farrel [mailto:adr...@olddog.co.uk]
  
  Sent: 21 July 2017 19:55


  
   
  Well,
  personally, if I was designing this, I would not a whole
  TLV for each bit flag!
  I would have
  a Setup-Type TLV.
  If that TLV
  is absent, RSVP-TE is supported.
  If the TLV is
  present, each bit means that a different setup type is
  supported.
   
  That means...
  Legacy nodes
  don't include the TLV and are assumed to support RSVP-TE
  Legacy nodes
  that receive the TLV don't know what it means and so
  object to the Open (leaving a new node to re-Open for
  RSVP-TE only).
  New nodes
  include the TLV and so indicate explicitly what they
  support.
   
  I know it is
  late for that type of change, so how we proceed might
  depend on what implementations have done already.
   
  Adrian
   
  

  
From: Pce [mailto:pce-boun...@ietf.org]
On Behalf Of Jonathan Hardwick
Sent: 21 July 2017 16:07
  
  

 
Dear PCE-ers
 
I don’t want to distract from the SDN
  topic too much, but we have an important decision to make
  about draft-ietf-pce-lsp-setup-type.
 
   

[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] Stateful PCE: inconsistency in "resource limit" text

[Julien Meuric]

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.

Thanks for your feedback,

Julien


May. 08, 2017 - cyril.marga...@gmail.com:
> Hi, 
>
> From what I recall, the limit exceeded can refer to the number of
> LSPs, memory, ..etc and the notification was introduced to support the
> same logic as rfc5440 "Overloaded PCE" notification.
>
> To keep that and to support soft/administrative limits, I am in favor
> of MAY terminate the session. If the Peer decides to terminate the
> session, a specific code must be used, otherwise the other peer will
> reconnect and the session will keep flapping.
>
> BR,
> Cyril
>
> On 8 May 2017 at 12:19, Jonathan Hardwick
>  > wrote:
>
> 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

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

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

[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

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

[Julien Meuric]

Hi Lionel,

Thank you for following up. I think we're almost done. My answers below
as [JM2].

Julien


Apr. 12, 2017 - >> =
>> [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.
>> 
> [LM2] "il faut être sorti de Saint-Cyr pour comprendre" as we say in
>  french :)

[JM2] Let me check with my colleague next door... ;-)

> Could be good to add something like "(as indicated by the U-bit clear
> in Stateful-capability-object)"

[JM2] ACK!

> 
>>> =
>>> 
>>> 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.
> [LM2] After multiple readings and thanks to your explanation, I think
> I have understood. Am I correct saying that the PCE will accept LSP
> Status Reports from a PCC ONLY if the stateful PCE capability has
> been advertised (i.e. Stateful Capability TLV with the 'LSP Update'
> Flag cleared)? 

[JM2] Almost... but not fully! Your main sentence is true, your
parenthesis is not. The latter should be rephrased as "i.e. inclusion of
the Stateful Capability TLV". Indeed, passive (report, no update) and
active (report + update) are two possible modes within stateful, i.e. we
do not care about the 'LSP Update' flag when talking about
Report/"stateful at large".

If it is the case, is it really required to keep this
> text, as in the previous paragraph we find the conditions to
> accept/reject reports from the PCC?

[JM2] AFAIU, the sentence clarifies the fact that an error on an update
attempt does not lead to an error on the report feature.

[JM2] Side note to the (RFC?) editor, on page 11: s/this draft/this
document/

___
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] RtgDir review: draft-ietf-pce-pce-initiated-lsp-09

[Julien Meuric]

Hi Vicky,

Thank you for your review and this helpful feedback. We'll make sure
they're addressed in the next revision.

Cheers,

Julien


Apr. 06, 2017 - pritchar...@gmail.com:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
>
> Document: draft-ietf-pce-pce-initiated-lsp-09.txt 
> Reviewer: Victoria Pritchard
> Review Date: 06 April 2017
> IETF LC End Date:  
> Intended Status: Standards Track
>
>
> Summary: 
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
>
> Comments:
> Although I was not very familiar with PCEP, I found the draft for the
> most part easy to understand, but did need to look up some things in
> the referenced documents and was unclear on a couple of small points.
> I have some suggestions that may help improve the draft for other
> readers, and I have some queries which may require clarification in
> the document. However, as most readers will be more familiar with the
> subject, perhaps not all comments will require any action.
>
>
> Major Issues:
> No major issues found.
>
>
> Minor Issues and Nits:
>
> Section 1, 1st paragraph
> Path Control Element / Path Computation Element ?
>
> Section 1, 2nd paragraph
> Stateful pce / Stateful PCE
> Reference link [I-D.ietf-pce-stateful-pce] points to section 3.1, not
> the references section. 
> The 2nd sentence was hard to read, could be split into two sentences.
>
> Section 2
> Last paragraph: Routing Backus-Naur Format / Routing Backus-Naur Form,
> to match the RFC title.
>
> Section 3.1
> At the end of the 1st paragraph, "possible agile software-driven
> network operation" is then repeated in the next paragraph as "A
> possible use case is a software-driven network"
>
> Section 3.2
> The acronyms SRP, PLSP and ERO are used a few times in this section.
> It may well be OK to assume most readers will be familiar with these,
> but would be good to have the expansion here too.
>
> Section 3.2, 3rd paragraph
> SRP-id-number / SRP-ID-number, for consistency
> The sentence beginning "The PCE MAY update" could be moved to a new
> paragraph, to separate it from the text regarding instantiation.
>
> Section 3.2, last paragraph
> Suggest to replace the "and" with a comma in this sentence: 
> "During State Synchronization, a PCC
>reports the state of its LSPs to the PCE using PCRpt messages and
>setting the SYNC flag in the LSP Object. "
> "include the Create Flag" / "set the Create Flag" - also the create
> flag has not yet been mentioned.
> Actually I think this overview could be much briefer and simpler.
> There is a lot of detail about objects, flags and options, which is
> explained in later sections but complicates this overview. I think it
> might be good to also summarise here what the extension adds in terms
> of messages and flags, to clearly indicate what's new compared to the
> referenced documents.
>
> Section 4
> After the first sentence, I would rephrase: "First, the Open message
> must include the Stateful PCE Capability TLV, defined in []." Then
> continue to the sentence beginning "A new flag is introduced in this
> TLV, ...".
>
> Section 4.1 
> In the flag bit description, "that the PCE may attempt to instantiate
> LSPs" could be changed to "that the PCE supports instantiating LSPs". 
> Also rather than "in order to support", use "in order to enable".
> Not sure this section is necessary in this form with Figure 1. For
> example, I think the sync-optimizations draft specifies flags in a
> nice way (Section 7 of that draft), suggesting the bit to use without
> a diagram. The description here in section 4.1 could be rolled into
> the main body of Section 4. Also, is there any need to mention the U
> flag or the S flag in this draft?
>
> I noticed a mix and match between terminology of
> "STATEFUL-PCE-CAPABILITY TLV" vs "Stateful PCE Capability" TLV - could
> be made consistent, I'd suggest "Stateful PCE Capability TLV"
> throughout for readability.
> Also the same applies to "Path Computation LSP Initiate Message",
> "Path Computation LSP Initiate Request", "LSP Initiate Message", "LSP
> Initiate Request", "LSP initiation request". Would be nice to see this
> consistent throughout.
>
> Section 5.1
> The 1st paragraph could be simplified by removing text about other
> objects and missing objects, and moving the final tw

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

[Pce] Building the PCE Agenda for IETF 98

[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

[Pce] CFP of iPOP2017

[Julien Meuric]

[Apologies, if you receive multiple copies of this CFP]  
  
Call for Presentation
 
13th International Conference on IP + Optical Network (iPOP 2017)   
June 1-2, 2017, Fujitsu Kawasaki Main Office, Kawasaki, Japan  
http://www.pilab.jp/ipop2017/   
 
Important Dates:  
  Submission deadline of one-page abstract:  February 24, 2017  
  Notification of acceptance:  April 4, 2017  
  Submission deadline of final presentation slides:  April 21, 2017  
 
The conference is intended to share the knowledge, new findings, and
experiences on the state-of-the art of IP and optical networking
technologies among the industry and the academia. It features technical
sessions and exhibitions. The opportunity to participate is open to all.  
 
The Technical Program Committee (TPC) for iPOP 2017 is soliciting
presentation proposals for this conference. Protocol design,
experiments, theories, implementations, and operational experiences are
solicited.
 
The topics of the conference will include but not be limited to the
following:
  * Optical networking/switching for cloud services  
  * Control plane (MPLS/GMPLS, OpenFlow, etc)  
  * SDN for packet and optical transport networks  
  * MLN/MRN (Multi-Layer/Region Networks)  
  * TE (Traffic Engineering), PCE (Path Computation Element)  
  * Network abstraction/virtualization  
  * Flex-grid, elastic optical networks  
  * Data center and WAN orchestration  
  * Carrier Ethernet and MPLS-TP for backhauling  
  * Service function chaining for mobile networks  
  * QoS/QoE (Quality of Service/Experience)  
  * Network operation and management  
  * Standardization/interoperability  
  * Network requirement for IoT  
  * Open Source Software (OSS) for SDN/NFV  
  * NFV/SDN expectation for 5G  
  * Control of network slices  
 
If you wish to submit a topic for consideration, please send an extended
abstract of 400 words and a maximum of 1 page, including figures and
diagrams, speakerfs name, affiliation, and contact information to the
TPC at ipop2017-...@pilab.jp.
 
Please see http://www.pilab.jp/ipop2017/ for more details.  


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

[Pce] Fwd: RFC Format Tools Development Contracts Awarded by IAOC

[Julien Meuric]

Hi all,

In case you overlooked it, please be aware of the ongoing work on new
RFC format. The tool development mentioned below follows the publication
of a set of RFCs in last December (starting from RFC 7990), which marked
a strong step towards the evolution of the RFC format.

Regards,

Julien


 Message transféré 
Date : Mon, 16 Jan 2017 10:06:31 -0800
De : IETF Administrative Director 

At the request of the IAOC the Internet Society issued an RFP on 20
September 2016 for the development of tools to support changes to
RFC formats, a project led by the RFC Series Editor, Heather
Flanagan.

On 22 December the IAOC awarded tools development contracts to
SeanTek and Elf Tools.

SeanTek will develop the RFClint, svgcheck, and XML Diff tools,
while Elf Tools will develop the IDNITS, Publication Formatter and
Text Submission tools.

The specifications were developed through a four-plus-year community
process that culminated in the following RFCs:

  a.  RFC 7991  The xml2rfc Version 3 Vocabulary
  b.  RFC 7992  HTML Format for RFCs
  c.  RFC 7994  Requirements for Plain-Text RFCs
  d.  RFC 7995  PDF Format for RFCs
  e.  RFC 7996  SVG Drawings for RFCs
  f.  RFC 7997  The Use of Non-ASCII Characters in RFC
  g.  RFC 7998  xml2rfc Version 3 Preparation Tool Description

SeanTek is led by Sean Leonard; Elf Tools, by Henrik Levkowetz.

Robert Sparks and Heather Flanagan will serve as the Project
Managers for the project.

Ray
IAD

___
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 init

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

[Julien Meuric]

Hi Aaron,

Thank for you comment.

As you point out, the current I-D has taken a timer-based approach:
- while State Timeout is not expired, decision is at the PCE level, any
PCE with ID knowledge may claim control (not necessarily granted);
- once State Timeout is expired, the PCC gets the decision.

What you are proposing could be a valuable enhancement, but at this
stage we would prefer to send this version that has been there and
implemented for a while. As a result, your proposal would deserve a new
extension draft, focusing on take-over negotiation, which could be
discussed with the WG.

Please feel free to proceed.

Best regards,

Julien


Jan. 05, 2017 - aitsk...@cisco.com:
> 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 initiated LSP. The existing
>> alternative is to rely on the PCE server to server communication for
>> detection of such events which is prone to errors.
>>
>> For example:
>>
>>   - loss of communication between PCE-A and PCE-B may be
>> interpreted as "takeover" trigger which is not necessarily true as
>> PCE-A<->PCC connection may still be up.
>>   - In case where PCE-A <-> PCC connection is down and both PCC
>> <-> PCE-B and  PCE-A <-> PCE-B connections are up we will need each
>> PCE server to distribute information about connection with it's
>> clients to all peers
>>
>> The suggestion frees PCE server from the need to propagate it's client
>> connection status to all other PCE servers.
>>
>> Let me know what you think
>>
>> Thanks
>> Aaron
>>
>> ___
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/ma

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

[Julien Meuric]

Hi,

With support and without objection, this confirms the consensus to adopt 
this I-D as a PCE WG item. Authors, please republish it as 
draft-ietf-pce-association-policy-00.


Thanks,

Jon, JP & Julien


Nov. 24, 2016 - 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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] 答复: Working group last call (including final IPR check) for draft-ietf-pce-wson-rwa-ext

[Julien Meuric]

  
  
Hi Haomian,

Thank you for your feedback. Would you mind pointing the editors to
the nits you spotted?

Cheers,

Julien

Dec. 02, 2016 -
  zhenghaom...@huawei.com:


  
  
  
  
Hi WG,

 
I
reviewed this draft and believe it is technically ready to
be published.

 
There
are still some nits need to be fixed before publication,
thank you.

 
Best
wishes,

Haomian
 

  
发件人:
Pce [mailto:pce-boun...@ietf.org]
  代表 Jonathan
Hardwick
  发送时间:
2016年11月23日 1:31

  

 
Dear PCE working group,
 
This email starts a
working group last call for draft-ietf-pce-wson-rwa-ext-05.
https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/
 
Please read the document
and reply to the PCE mailing list whether you believe this
document is ready to be published, or not (including any
comments on why not).  The last call will end on
Tuesday 6 December.
 
We are also polling for
knowledge of any undisclosed IPR that applies to
draft-ietf-pce-wson-rwa-ext-05, to ensure that IPR has been
disclosed in compliance with IETF IPR rules (see RFCs 3979,
4879, 3669 and 5378 for more details) prior to moving
forward.  If you are a document author, please respond to
this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The document won't progress
without answers from all the authors.  No IPR disclosures
currently exist against this document.
 
Many thanks
Jon, Julien and JP
 
 
  


  


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/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