[Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-03.txt

[internet-drafts]

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

Title   : PCEP Extension for Native IP Network
Authors : Aijun Wang
  Boris Khasanov
  Sudhir Cheruathur
  Chun Zhu
  Sheng Fang
Filename: draft-ietf-pce-pcep-extension-native-ip-03.txt
Pages   : 10
Date: 2019-03-07

Abstract:
   This document defines the PCEP extension for CCDR application in
   Native IP network.  The scenario and architecture of CCDR in native
   IP is described in [I-D.ietf-teas-native-ip-scenarios] and
   [I-D.ietf-teas-pce-native-ip].  This draft describes the key
   information that is transferred between PCE and PCC to accomplish the
   end2end traffic assurance in Native IP network under central control
   mode.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-03
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-native-ip-03


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

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

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

[Pce] I-D Action: draft-ietf-pce-applicability-actn-10.txt

[internet-drafts]

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

Title   : Applicability of the Path Computation Element (PCE) 
to the Abstraction and Control of TE Networks (ACTN)
Authors : Dhruv Dhody
  Young Lee
  Daniele Ceccarelli
Filename: draft-ietf-pce-applicability-actn-10.txt
Pages   : 21
Date: 2019-03-07

Abstract:
   Abstraction and Control of TE Networks (ACTN) refers to the set of
   virtual network (VN) operations needed to orchestrate, control and
   manage large-scale multi-domain TE networks so as to facilitate
   network programmability, automation, efficient resource sharing, and
   end-to-end virtual service aware connectivity and network function
   virtualization services.

   The Path Computation Element (PCE) is a component, application, or
   network node that is capable of computing a network path or route
   based on a network graph and applying computational constraints.  The
   PCE serves requests from Path Computation Clients (PCCs) that
   communicate with it over a local API or using the Path Computation
   Element Communication Protocol (PCEP).

   This document examines the applicability of PCE to the ACTN
   framework.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-applicability-actn-10
https://datatracker.ietf.org/doc/html/draft-ietf-pce-applicability-actn-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-applicability-actn-10


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

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

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

[Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-10.txt

[internet-drafts]

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

Title   : Path Computation Element (PCE) Protocol Extensions 
for Stateful PCE Usage in GMPLS-controlled Networks
Authors : Young Lee
  Fatai Zhang
  Ramon Casellas
  Oscar Gonzalez de Dios
  Zafar Ali
Filename: draft-ietf-pce-pcep-stateful-pce-gmpls-10.txt
Pages   : 13
Date: 2019-03-07

Abstract:
   The Path Computation Element (PCE) facilitates Traffic Engineering
   (TE) based path calculation in large, multi-domain, multi-region, or
   multi-layer networks. The PCE communication Protocol (PCEP) has been
   extended to support stateful PCE functions where the PCE retains
   information about the paths already present in the network, but
   those extensions are technology-agnostic. This memo provides
   extensions required for PCEP so as to enable the usage of a stateful
   PCE capability in GMPLS-controlled networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-10
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpls-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-10


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

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

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

Re: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt

[Leeyoung]

Hi Adrian,

Please take my/our apology for the delayed response. I am working on it now, 
hopefully we can upload the revision either today or by tomorrow. 

Thanks.
Young

-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Thursday, March 7, 2019 4:15 PM
To: draft-ietf-pce-pcep-stateful-pce-gm...@ietf.org
Cc: pce@ietf.org
Subject: RE: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt

Hi authors,

Unless I am mistaken, there was never a response to my review back in December. 
 Did it get lost (I see it in the list archive)?

Plans?

Thanks,
Adrian
-Original Message-
From: Adrian Farrel 
Sent: 05 December 2018 18:17
To: 'Leeyoung' ; 'pce@ietf.org' 
Subject: RE: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt

While I'm on a roll reviewing PCE documents, and while Young is being active, I 
just had a look at his new revision on this draft.

Glad that it is alive again because we seem to have a number of documents that 
relate to it.

Only a few comments, but I think tidying these gets us close to "done".

Thanks,
Adrian
===

You should move "Conventions used in this document" down to become Section 2 
and replace it with the new text...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

That requires you to make an addition to the normative references for RFC 8174.

---

2.
OLD
   For Passive Stateful PCE where PCReq/PCRep messages are used to
   convey path computation instruction.  As GMPLS-technology specific
   Objects/TLVs are defined in [PCEP-GMPLS], this document just points
   to the work in [PCEP-GMPLS] and add only the stateful PCE aspect
   only if applicable.
NEW
   For Passive Stateful PCEs, PCReq/PCRep messages are used to convey
   path computation instructions.  GMPLS-technology specific Objects and
   TLVs are defined in [PCEP-GMPLS], so this document just points at
   that work and only adds the stateful PCE aspects where applicable.
END

---

4.2

You have "ERO object" and "RRO object". That would be EROO and RROO?
I think that if you expand the terms on first use, then the use of the 
abbreviations will be easier.

In the same section you have IRO and XRO which you should expand.

---

4.2 needs a reference to RFC 5511. I suggest...

OLD
   To be more specific, the  is updated as
   follows:
NEW
   To be more specific, the  is updated as
   follows using the notation of [RFC5511]:
END

Obviously, you need to add that to the references section as well.

---

At the end of 4.2 you have

   Moreover, if the status
   of the protecting LSP changes from non-operational to operational,
   this SHOULD to be synchronized to the stateful PCE using a PCRpt
   message.

Reviewers are likely to ask "under what circumstances can an implementation 
vary this procedure and why?"

You may also get asked about the use of the passive voice in this sentence. Who 
should synchonise it to the stateful PCE?

---

The final sentence of 4.3 says...

   Note this MAY also be applicable to packet
   networks.

I think probably s/MAY also be/is also/

---

4.3.2

You rightly say...

 X bit and Attribute fields are defined in [RFC5521].

So you can safely (should) delete ...

 X bit: indicates whether the exclusion is mandatory (X=1) and MUST
 be accommodated, or desired (X=0) and SHOULD be accommodated.

 and ...

 Attributes: indicates how the exclusion object is to be
 interpreted. Currently, Interface (Attributes = 0), Node
 (Attributes =1) and SRLG (Attributes =2) are defined in [RFC5521]
 and this document does not define new values.

---

4.3.2 s/a LSP/an LSP/

---

4.3.2 s/exclude it from the/exclude from the/

---

I'm trying to reconcile 4.3.3 with 5.3. The problems are:

- 5.3 "new registry" but I think the registry already exists
- 5.3 (correctly) says that the new bit position is TBD allowing IANA
  to make the best selection, but Figure 3 shows a specific position
  for the B-bit

I would replace the text in the two sections as follows...

4.3.3
OLD
   The format of the SRP object is defined in [RFC8231] and included
   here for easy reference with the addition of the new B flag. This
   SRP object is used in PCUpd and PCInit messages for GMPLS.



0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Flags|B|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SRP-ID-number  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|

Re: [Pce] WG Last Call completed for draft-ietf-pce-applicability-actn

[Adrian Farrel]

Hi,

Thanks for this revision which is practically perfect.

Sadly, the RFC Editor requires that the first section of a document is the
Introduction. I think it would be fine to swap your sections 1 and 2.

You asked me at the end of February to have a look at your proposed Security
text, and I have done now. I think you have gone a long way towards doing
the right thing, and I'm comfortable with the idea of putting this in front
of the Security experts.

You need to post a quick update to swap the first two sections. While you do
that I'll write the Shepherd Write-up.

Then we will ask the AD to advance it.

Thanks,
Adrian

-Original Message-
From: Dhruv Dhody  
Sent: 07 March 2019 09:36
To: adr...@olddog.co.uk; pce@ietf.org
Cc: Dhruv Dhody 
Subject: RE: [Pce] WG Last Call completed for
draft-ietf-pce-applicability-actn

Hi Adrian, WG, 

We have posted a new version -09 that addresses WG LC comments (from Adrian
and Dan). 

I-D: https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-applicability-actn-09

Please have a look and let us know if any further changes needs to be made. 

Thanks! 
Dhruv, Young & Daniele

--
Dhruv Dhody 
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066 
Tel: + 91-80-49160700 Ext 71583 II Email: dhruv.dh...@huawei.com

This e-mail and its attachments contain confidential information from
HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any
use of the 
information contained herein in any way (including, but not limited to,
total or partial 
disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by 
phone or email immediately and delete it!


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 25 February 2019 18:24
> To: pce@ietf.org
> Subject: [Pce] WG Last Call completed for draft-ietf-pce-applicability-
> actn
> 
> Hi,
> 
> The WG last call completed without any dissent, but with only a few
> comments of support.
> 
> There were some issues raised (including from Dan and me).
> 
> Authors:
> Please post a revision that addresses the comments.
> 
> Working Group:
> Please continue to send messages of support so that we know that this
> draft really should be advanced.
> 
> Thanks,
> Adrian
> 
> -Original Message-
> From: Pce  On Behalf Of Adrian Farrel
> Sent: 08 February 2019 11:34
> To: pce@ietf.org
> Subject: [Pce] WG Last Call on draft-ietf-pce-applicability-actn
> 
> Hi WG,
> 
> draft-ietf-pce-applicability-actn seems to be ready to progress towards
> publication.
> 
> This email starts a two week working group last call (ends on 23rd
> February).
> 
> During this time, please read the draft and make comments for improvement.
> If you then support its publication please let us know that you have read
> the draft and support it. If you have any concerns, please let us know and
> propose solutions.
> 
> Thanks,
> Adrian
> 
> ___
> 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

[Pce] I-D Action: draft-ietf-pce-association-group-08.txt

[internet-drafts]

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

Title   : PCEP Extensions for Establishing Relationships 
Between Sets of LSPs
Authors : Ina Minei
  Edward Crabbe
  Siva Sivabalan
  Hariharan Ananthakrishnan
  Dhruv Dhody
  Yosuke Tanaka
Filename: draft-ietf-pce-association-group-08.txt
Pages   : 28
Date: 2019-03-07

Abstract:
   This document introduces a generic mechanism to create a grouping of
   Label Switched Paths (LSPs) in the context of a Path Computation
   Element (PCE).  This grouping can then be used to define associations
   between sets of LSPs or between a set of LSPs and a set of attributes
   (such as configuration parameters or behaviors), and is equally
   applicable to the stateful PCE (active and passive modes) as well as
   the stateless PCE.



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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-association-group-08
https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-group-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-08


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

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

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

Re: [Pce] Shepherd Review of draft-ietf-pce-association-group-06

[julien.meuric]

This sentence is clear enough to address my concern.

Thank you!

Julien


On 07/03/2019 15:00, Dhruv Dhody wrote:
> Hi Julien, 
>
> My bad! 
> I did some digging and we added this based on Adrian's comment [1]
> back in Feb last year (and my memory failed me). 
>
> How about - 
>
>    The Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE
>    TLV in the case of a non-contiguous Operator-configured Association
>    Range.  The PCEP speaker originating this TLV MUST NOT carry
>    overlapping ranges for an association type.  If a PCEP peer receives
>    overlapping ranges for an association type, it MUST consider the Open
>    message malformed and MUST reject the PCEP session with error type 1
>    and error value 1 (PCEP session establishment failure / Reception of
>    an invalid Open message).
>
> Thanks! 
> Dhruv 
>
> [1] https://mailarchive.ietf.org/arch/msg/pce/QSobS2pul-lIlMLXV4KcBhwgBM0
>
> On Thu, Mar 7, 2019 at 6:45 PM  > wrote:
>
> Hi Dhruv,
>
> Congratulation from the prompt update. I'm fine with the 
> notation
> for ranges.
>
> The only open issue is the text you add below:
> - Is there a reason to prohibit, for a given Association type, split
> operator-configured ranges? I don't think this is what the original
> version suggested.
> - Assuming we proceed with this new rule, then why so much text about
> overlapping ranges? To have this happen, the TLV would already break
> that "present only once" rule: why would an implementation care about
> checking if ranges overlap if the TLV is already wrong?
>
> Thanks,
>
> Julien
>
>
> On 07/03/2019 09:28, Dhruv Dhody wrote:
> >> --
> >> 5.1. Procedure
> >> ---
> >> - The current text only indirectly tackles the case where a
> given Assoc-
> >> type is advertised multiple times, when forbidding overlapping
> ranges. A
> >> complementary sentence explicitly mentioning non-overlapping
> ranges would
> >> be welcome.
> > [[Dhruv Dhody]] Added -
> >
> >    An Assoc-Type MUST be present only once in the
> OP-CONF-ASSOC-RANGE
> >    TLV, if the same Assoc-Type is present more than once, the PCEP
> >    session MUST be rejected with error type 1 and error value 1
> (PCEP
> >    session establishment failure / Reception of an invalid Open
> >    message).
> >
>
> 
> _
>
> 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.
>


_

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] WG Last Call completed for draft-ietf-pce-applicability-actn

[Jeff Tantsura]

Yes/support

Cheers,
Jeff

> On Mar 7, 2019, at 1:35 AM, Dhruv Dhody  wrote:
> 
> Hi Adrian, WG, 
> 
> We have posted a new version -09 that addresses WG LC comments (from Adrian 
> and Dan). 
> 
> I-D: https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-applicability-actn-09
> 
> Please have a look and let us know if any further changes needs to be made. 
> 
> Thanks! 
> Dhruv, Young & Daniele
> 
> --
> Dhruv Dhody 
> Lead Architect
> Network Business Line
> Huawei Technologies India Pvt. Ltd.
> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
> Bengaluru, Karnataka - 560066 
> Tel: + 91-80-49160700 Ext 71583 II Email: dhruv.dh...@huawei.com
> 
> This e-mail and its attachments contain confidential information from HUAWEI, 
> which 
> is intended only for the person or entity whose address is listed above. Any 
> use of the 
> information contained herein in any way (including, but not limited to, total 
> or partial 
> disclosure, reproduction, or dissemination) by persons other than the 
> intended 
> recipient(s) is prohibited. If you receive this e-mail in error, please 
> notify the sender by 
> phone or email immediately and delete it!
> 
> 
>> -Original Message-
>> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
>> Sent: 25 February 2019 18:24
>> To: pce@ietf.org
>> Subject: [Pce] WG Last Call completed for draft-ietf-pce-applicability-
>> actn
>> 
>> Hi,
>> 
>> The WG last call completed without any dissent, but with only a few
>> comments of support.
>> 
>> There were some issues raised (including from Dan and me).
>> 
>> Authors:
>> Please post a revision that addresses the comments.
>> 
>> Working Group:
>> Please continue to send messages of support so that we know that this
>> draft really should be advanced.
>> 
>> Thanks,
>> Adrian
>> 
>> -Original Message-
>> From: Pce  On Behalf Of Adrian Farrel
>> Sent: 08 February 2019 11:34
>> To: pce@ietf.org
>> Subject: [Pce] WG Last Call on draft-ietf-pce-applicability-actn
>> 
>> Hi WG,
>> 
>> draft-ietf-pce-applicability-actn seems to be ready to progress towards
>> publication.
>> 
>> This email starts a two week working group last call (ends on 23rd
>> February).
>> 
>> During this time, please read the draft and make comments for improvement.
>> If you then support its publication please let us know that you have read
>> the draft and support it. If you have any concerns, please let us know and
>> propose solutions.
>> 
>> Thanks,
>> Adrian
>> 
>> ___
>> 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

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

Re: [Pce] Shepherd Review of draft-ietf-pce-association-group-06

[Dhruv Dhody]

Hi Julien,

My bad!
I did some digging and we added this based on Adrian's comment [1] back in
Feb last year (and my memory failed me).

How about -

   The Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE
   TLV in the case of a non-contiguous Operator-configured Association
   Range.  The PCEP speaker originating this TLV MUST NOT carry
   overlapping ranges for an association type.  If a PCEP peer receives
   overlapping ranges for an association type, it MUST consider the Open
   message malformed and MUST reject the PCEP session with error type 1
   and error value 1 (PCEP session establishment failure / Reception of
   an invalid Open message).

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/QSobS2pul-lIlMLXV4KcBhwgBM0

On Thu, Mar 7, 2019 at 6:45 PM  wrote:

> Hi Dhruv,
>
> Congratulation from the prompt update. I'm fine with the  notation
> for ranges.
>
> The only open issue is the text you add below:
> - Is there a reason to prohibit, for a given Association type, split
> operator-configured ranges? I don't think this is what the original
> version suggested.
> - Assuming we proceed with this new rule, then why so much text about
> overlapping ranges? To have this happen, the TLV would already break
> that "present only once" rule: why would an implementation care about
> checking if ranges overlap if the TLV is already wrong?
>
> Thanks,
>
> Julien
>
>
> On 07/03/2019 09:28, Dhruv Dhody wrote:
> >> --
> >> 5.1. Procedure
> >> ---
> >> - The current text only indirectly tackles the case where a given Assoc-
> >> type is advertised multiple times, when forbidding overlapping ranges. A
> >> complementary sentence explicitly mentioning non-overlapping ranges
> would
> >> be welcome.
> > [[Dhruv Dhody]] Added -
> >
> >An Assoc-Type MUST be present only once in the OP-CONF-ASSOC-RANGE
> >TLV, if the same Assoc-Type is present more than once, the PCEP
> >session MUST be rejected with error type 1 and error value 1 (PCEP
> >session establishment failure / Reception of an invalid Open
> >message).
> >
>
>
> _
>
> 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] Shepherd Review of draft-ietf-pce-association-group-06

[julien.meuric]

Hi Dhruv,

Congratulation from the prompt update. I'm fine with the  notation
for ranges.

The only open issue is the text you add below:
- Is there a reason to prohibit, for a given Association type, split
operator-configured ranges? I don't think this is what the original
version suggested.
- Assuming we proceed with this new rule, then why so much text about
overlapping ranges? To have this happen, the TLV would already break
that "present only once" rule: why would an implementation care about
checking if ranges overlap if the TLV is already wrong?

Thanks,

Julien


On 07/03/2019 09:28, Dhruv Dhody wrote:
>> --
>> 5.1. Procedure
>> ---
>> - The current text only indirectly tackles the case where a given Assoc-
>> type is advertised multiple times, when forbidding overlapping ranges. A
>> complementary sentence explicitly mentioning non-overlapping ranges would
>> be welcome.
> [[Dhruv Dhody]] Added - 
>
>An Assoc-Type MUST be present only once in the OP-CONF-ASSOC-RANGE
>TLV, if the same Assoc-Type is present more than once, the PCEP
>session MUST be rejected with error type 1 and error value 1 (PCEP
>session establishment failure / Reception of an invalid Open
>message).
>

_

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] WG Last Call completed for draft-ietf-pce-applicability-actn

[Dhruv Dhody]

Hi Adrian, WG, 

We have posted a new version -09 that addresses WG LC comments (from Adrian and 
Dan). 

I-D: https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-applicability-actn-09

Please have a look and let us know if any further changes needs to be made. 

Thanks! 
Dhruv, Young & Daniele

--
Dhruv Dhody 
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066 
Tel: + 91-80-49160700 Ext 71583 II Email: dhruv.dh...@huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, 
which 
is intended only for the person or entity whose address is listed above. Any 
use of the 
information contained herein in any way (including, but not limited to, total 
or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by 
phone or email immediately and delete it!


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 25 February 2019 18:24
> To: pce@ietf.org
> Subject: [Pce] WG Last Call completed for draft-ietf-pce-applicability-
> actn
> 
> Hi,
> 
> The WG last call completed without any dissent, but with only a few
> comments of support.
> 
> There were some issues raised (including from Dan and me).
> 
> Authors:
> Please post a revision that addresses the comments.
> 
> Working Group:
> Please continue to send messages of support so that we know that this
> draft really should be advanced.
> 
> Thanks,
> Adrian
> 
> -Original Message-
> From: Pce  On Behalf Of Adrian Farrel
> Sent: 08 February 2019 11:34
> To: pce@ietf.org
> Subject: [Pce] WG Last Call on draft-ietf-pce-applicability-actn
> 
> Hi WG,
> 
> draft-ietf-pce-applicability-actn seems to be ready to progress towards
> publication.
> 
> This email starts a two week working group last call (ends on 23rd
> February).
> 
> During this time, please read the draft and make comments for improvement.
> If you then support its publication please let us know that you have read
> the draft and support it. If you have any concerns, please let us know and
> propose solutions.
> 
> Thanks,
> Adrian
> 
> ___
> 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

[Pce] I-D Action: draft-ietf-pce-applicability-actn-09.txt

[internet-drafts]

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

Title   : Applicability of the Path Computation Element (PCE) 
to the Abstraction and Control of TE Networks (ACTN)
Authors : Dhruv Dhody
  Young Lee
  Daniele Ceccarelli
Filename: draft-ietf-pce-applicability-actn-09.txt
Pages   : 21
Date: 2019-03-07

Abstract:
   Abstraction and Control of TE Networks (ACTN) refers to the set of
   virtual network (VN) operations needed to orchestrate, control and
   manage large-scale multi-domain TE networks so as to facilitate
   network programmability, automation, efficient resource sharing, and
   end-to-end virtual service aware connectivity and network function
   virtualization services.

   The Path Computation Element (PCE) is a component, application, or
   network node that is capable of computing a network path or route
   based on a network graph and applying computational constraints.  The
   PCE serves requests from Path Computation Clients (PCCs) that
   communicate with it over a local API or using the Path Computation
   Element Communication Protocol (PCEP).

   This document examines the applicability of PCE to the ACTN
   framework.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-applicability-actn-09
https://datatracker.ietf.org/doc/html/draft-ietf-pce-applicability-actn-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-applicability-actn-09


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

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

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

Re: [Pce] Shepherd Review of draft-ietf-pce-association-group-06

[Dhruv Dhody]

Hi Julien, 

Thanks for your detailed review and providing suggested text. 

Here is the working copy - 
https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-08.txt
Diff - 
https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-association-group-06=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-08.txt

> --
> 4.1.1. Procedure
> ---
> - The last sentence of the paragraph puzzled me a bit. The current wording
> may suggests that "it is RECOMMENDED to support the aforementioned
> OPTIONAL TLV", which is inconsistent 2119 language. My guess is that it
> should say: "In case the use of the ASSOC-Type-List TLV is triggered by a
> mandatory association type, then it is RECOMMENDED that the PCEP
> implementation include..." Is my understanding correct?

[[Dhruv Dhody]] That is correct. Updated.

> --
> 5.1. Procedure
> ---
> - The current text only indirectly tackles the case where a given Assoc-
> type is advertised multiple times, when forbidding overlapping ranges. A
> complementary sentence explicitly mentioning non-overlapping ranges would
> be welcome.
[[Dhruv Dhody]] Added - 

   An Assoc-Type MUST be present only once in the OP-CONF-ASSOC-RANGE
   TLV, if the same Assoc-Type is present more than once, the PCEP
   session MUST be rejected with error type 1 and error value 1 (PCEP
   session establishment failure / Reception of an invalid Open
   message).


> --
> Appendix A.
> ---
> - I am not comfortable with reading ranges in round brackets. Have square 
> brackets been considered?
> - I am not sure about the meaning of the sentence "not PCC or PCE as set
> as NMS id", please rephrase.

 [[Dhruv Dhody]] In case the association source is not a PCEP peer (for
   example an NMS system), then the default range of <0x1000, 0x> is
   considered.

Use of [] throws idnits, and thus I am using <>. 

Thanks again for your review. 

Regards,
Dhruv

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