Re: [Pce] WG Adoption of draft-rajagopalan-pce-pcep-color-02

[Cyril Margaria]

I have read the document and I think it should be adopted as WGdocument.
 The functionality proposed is of interest and the mechanism align well
with other use cases.

Thanks,
Cyril

On Thu, 1 Dec 2022 at 05:07, Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for
> draft-rajagopalan-pce-pcep-color-02.
>
> https://datatracker.ietf.org/doc/draft-rajagopalan-pce-pcep-color/
>
> Should this draft be adopted by the PCE WG? Please state your reasons -
> Why / Why not? What needs to be fixed before or after adoption? Are you
> willing to work on this draft? Review comments should be posted to the list.
>
> Please respond by Friday 16th Dec 2022.
>
> Please be more vocal during WG polls!
>
> Thanks!
> Dhruv & 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] Scoping Items from draft-koldychev-pce-operational

[Cyril Margaria]

Hi

I also prefer two documents because they should (IMHO) be in two
different Categories.
The split proposed by Dhruv makes sense in that regards.

Thanks,
Cyril


On Thu, 10 Nov 2022 at 22:54, Dhruv Dhody  wrote:

> Hi,
>
> It is likely I might be rough on this, but wanted to put my thoughts on
> the list as well (I said as much in the last IETF meeting).
>
> My preference (as a WG participant) is for two documents -
> (1) A very small standards track I-D that updates RFC 8231 with clear
> old/new text on what is being updated
> (2) A larger informational I-D that matches the name "operational
> clarification" on how things works with figures and explanations
>
> For (1) see RFC 8786 as reference! For (2) see RFC 6007 as a clarification
> document for SVEC.
>
> IMHO this separation and clear focused I-D serve the WG well :)
>
> We can discuss this during the WG session tomorrow! I have added it to the
> WG chairs slide as a discussion point!
>
> Thanks!
> Dhruv
>
> On Thu, Sep 29, 2022 at 9:37 AM  wrote:
>
>> Dear PCE WG,
>>
>> Let's follow up on the discussion started during IETF 114 about
>> draft-koldychev-pce-operational [1]. The I-D currently tackles different
>> issues about PCEP, some of them being informational, some other updating
>> existing PCEP specifications. Among the options we discussed to proceed
>> with this work, 2 remain:
>> 1. Keep a single draft, but clearly separate the two types of content;
>> 2. Break it up into 2 drafts.
>>
>> We'd like to hear the WG's opinion whether you prefer:
>> a- a single standard track I-D, with both content types sharing fate
>> until publication?
>> b- a clarification I-D on informational track + an I-D updating PCEP on
>> standard track (possibly progressing at different paces)?
>>
>> Please share your feedback using the PCE mailing list.
>>
>> Thanks,
>>
>> Dhruv & Julien
>>
>>
>> [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/
>>
>>
>> ___
>> 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] Adoption of draft-xiong-pce-lsp-flag-03

[Cyril Margaria]

Support,

I have the following comments:
  - The TLV is, as specified, is not forbidden  in other PCEP Objects,
  - It might be only defined as LSP object TLV and error code defined for
other cases, but it could also be allowed in any object and the extended
flags defined themselves within the context of an object.

BR
Cyril

On Thu, 4 Feb 2021 at 09:14, Dhruv Dhody  wrote:

> Hi WG,
>
> Greg, Quan, and I discussed this offline and have this proposed text -
>
> Note that, PCEP peers MAY encounter different length of the
> LSP-EXTENDED-FLAG TLV.
>
>o If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV
>  of a length more than it currently supports or understands,
>  it will simply ignore the bits beyond that length.
>
>o If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of
>  a length less than the one supported by the implementation,
>  it will consider the bits beyond the length to be unset.
>
> Thoughts?
>
> Dhruv (as a WG member)
>
>
> On Thu, Feb 4, 2021 at 2:34 AM Greg Mirsky  wrote:
>
>> Dear All,
>> I've read the draft and support it being adopted by the PCE WG. The draft
>> provides an elegant future-proof solution to the real problem. I have one
>> suggestion for a future revision of this document. You've already
>> considered backward compatibility between implementations that support the
>> new TLV and ones that do not. I think we can envision a situation when
>> implementations with, for example, 32 bit-long LSP Extended Flags field
>> interwork with implementations that use 64 bit-long field. Such a situation
>> might be far away today but it might help developers later. Also, might be
>> helpful to explicitly note that the value in the Length field equals the
>> length of the LSP Extended Flags field in octets (some bytes used to be
>> only seven-bit-long).
>>
>> Regards,
>> Greg
>>
>> On Mon, Feb 1, 2021 at 9:48 AM Dhruv Dhody  wrote:
>>
>>> Hi WG,
>>>
>>> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>>>
>>> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03
>>>
>>> This is a small draft that extends the flags in the LSP Objects by
>>> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
>>> sub-registry "LSP Object Flag Field" is almost fully assigned.
>>>
>>> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field
>>>
>>> Should this draft be adopted by the PCE WG? Please state your reasons
>>> - Why / Why not? What needs to be fixed before or after adoption? Are
>>> you willing to work on this draft? Review comments should be posted to
>>> the list.
>>>
>>> Please respond by Monday 15th Feb.
>>>
>>> Thanks!
>>> Dhruv & 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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Cyril Margaria]

Hi Mike

On Fri, 6 Nov 2020 at 14:09, Mike Koldychev (mkoldych) 
wrote:

> Hi Dhruv,
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Friday, November 6, 2020 8:27 AM
> To: Mike Koldychev (mkoldych) 
> Cc: Dhruv Dhody ; pce-chairs ;
> pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril
> Margaria ; Stone, Andrew (Nokia - CA/Ottawa) <
> andrew.st...@nokia.com>
> Subject: Re: [Pce] Association Source in
> draft-ietf-pce-segment-routing-policy-cp-01
>
> Hi Mike,
>
> On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych)  40cisco@dmarc.ietf.org> wrote:
> >
> > Hi Dhruv,
> >
> > I don't think it's valid to dismiss race conditions in the protocol
> because they are "rare". If they can happen at all means that
> implementations need to have extra logic to handle these race conditions.
> >
>
> Doesn't this "extra" logic exist anyway, as you must make sure there is
> only one SR policy association with a given set of SR Policy parameters
> under normal operations.
>
> [MK] If the PCC allocates the Association Source/ID, then it's always
> going to choose a unique value, so there will never be any collision. So
> no, this "extra" logic won't exist if we go with my proposal.
>

[MC] that's assuming that the PCE always sends 0, and not the previously
returned value, at that point why bother using or tracking association ?



>
>
> BTW, what are your thoughts on the operator-configured association in the
> previous email? Not viable?
>
> [MK] You could set AssocExtID=Color, but I’m not sure what you would set
> Source to? Can we just set it to 0.0.0.0/0::0 and be done? Isn't that
> also a "special value"?
>

AssocExtID=Color, endpoint

Source should be a valid IP address, 0.0.0.0 looks OK, but I am rusty on
that.
0 is reserved, 0x is all assocation, 1 works as a fixed number not in a
reserved range.


>
> > All of this can be avoided if we just allow Source/ID to be 0 in PCInit
> messages. Is that really such a big change?
> >
>
> No, but the WG worked on RFC 8697 to make sure all the associations can be
> handled in a common way as much as possible. When deviating from that, IMHO
> a higher bar should be met. The WG should ponder if it is met here based on
> the scenario described above, that's all.
>
> [MK] I fully understand, but the value of 0 is reserved in that RFC. Can
> each application use 0/0.0.0.0/0::0 for its own purpose? Is that
> allowed/forbidden in the RFC?
>

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

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Cyril Margaria]

I have a related question: how do you define the "PCC address", PCEP
session address , one router id?

For the association source race condition, the race condition will result
in a "Conflicting SRPAG TLV" from a PCInitiate/PCUpd, the PCE can use the
correct SRPAG.




On Thu, 5 Nov 2020 at 16:16, Dhruv Dhody  wrote:

> Hi Mike,
>
> On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych)
>  wrote:
> >
> > Hi Dhruv,
> >
> >
> >
> > Perhaps we can avoid this by letting PCE send PCInitiate message with
> Association Source set to some reserved value, like 0. This can mean that
> the PCE is basically requesting the PCC to allocate an Association Source
> and to “own” that Association. We already do this with the Association ID.
> PCE sets the ID to 0 in PCInitiate and PCC chooses an Association ID and
> reports it back.
> >
> >
>
> The comment was applicable for association-id as well as
> association-source! The use of 0 as association ID is being introduced
> by your draft and not part of the base RFC 8697 and that triggered the
> original email. Julien and I were uncomfortable with that and wanted
> to understand what is new here for SR policy association that requires
> a new procedure and cant be handled by RFC 8697.
>
> Thanks,
> Dhruv
>
> >
> > Thanks,
> >
> > Mike.
> >
> >
> >
> > From: Dhruv Dhody 
> > Sent: Thursday, November 5, 2020 10:43 AM
> > To: Mike Koldychev (mkoldych) 
> > Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org;
> pce-chairs 
> > Subject: Re: Association Source in
> draft-ietf-pce-segment-routing-policy-cp-01
> >
> >
> >
> > Hi Mike,
> >
> >
> >
> > On Thu, Nov 5, 2020 at 7:51 PM Mike Koldychev (mkoldych) <
> mkold...@cisco.com> wrote:
> >
> > Hi Dhruv,
> >
> >
> >
> > Thanks for bringing this up.
> >
> >
> >
> > By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that:
> >
> > all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND
> > they agree without talking to each other.
> >
> >
> >
> > In your proposal below, if we set ASSO_SOURCE = NMS_ADDRESS, it seems
> that condition 1 may be fulfilled, but it requires exchange of PCRupt/PCUpd
> messages between the 3 entities, which violates condition 2. Please correct
> me if I misunderstood something. In the picture that you drew, you say that
> “Policy Endpoint=X” and “Association Source=X”, are you suggesting to use
> the policy endpoint as the ASSO_SOURCE? That would satisfy both conditions,
> but I’m not sure if you intended that?
> >
> >
> >
> >
> >
> > No, I did not!
> >
> >
> >
> >
> >
> > I believe condition 2 is important to satisfy, because otherwise there
> could be race conditions where the 3 parties have different ASSOC_SOURCE
> for the same policy. Consider what happens when all 3 parties try to create
> the same policy at the same time.
> >
> >
> >
> >
> >
> > The SR-Policy association is "dynamic" in nature, and we need to go by
> the association parameters we receive from the PCEP peer. Condition 2 of
> talking to each other is the very nature of a dynamic association!
> >
> >
> >
> > If the race condition is the issue to solve, we can use the SR-Policy
> parameters (color, endpoint, source). And make sure there is only one
> SR-Policy-association-group with a given set of SR-Policy parameters (and
> generate an error otherwise). The other PCE would learn about the
> association and can use it subsequently!
> >
> >
> >
> > I’m open to any proposal, but IMO we should respect the above two
> requirements.
> >
> >
> >
> >
> >
> > I feel the requirement 2 is not compatible with a dynamic association.
> >
> >
> >
> > Thanks!
> >
> > Dhruv
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Mike.
> >
> >
> >
> > From: Dhruv Dhody 
> > Sent: Thursday, November 5, 2020 1:59 AM
> > To: draft-ietf-pce-segment-routing-policy...@ietf.org
> > Cc: pce@ietf.org; pce-chairs 
> > Subject: Association Source in
> draft-ietf-pce-segment-routing-policy-cp-01
> >
> >
> >
> > Hi Authors,
> >
> > In
> https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-01#section-4.2,
> you state -
> >
> >The Association Source MUST be set to the PCC's address.  This
> >applies for both PCC-initiated and PCE-initiated candidate paths.
> >The reasoning for this is that if different PCEs could set their own
> >Association Source, then the candidate paths instantiated by
> >different PCEs would by definition be in different PCEP Associations,
> >which contradicts our requirement that the SR Policy is represented
> >by an Association.
> >
> >
> >
> >
> >The Association ID MUST be chosen by the PCC when the SR policy is
> >allocated.  In PCRpt messages from the PCC, the Association ID MUST
> >be set to the unique value that was allocated by the PCC at the time
> >of policy creation.  In PCInit messages from the PCE, the Association
> >ID MUST be set to the reserved value 0, which indicates that the PCE
> >is asking the PCC to choose an ID value.  The PCE MUST NOT send the
> >

Re: [Pce] Multipath / replication segment comment

[Cyril Margaria]

continued inline

 ,

>
> [Cyril] There is a related work that ties one tunnel to multiple path,
> list of hops :  RFC8697, and draft-ietf-pce-stateful-path-protection-11.
> Given the mechanism used (and flexibility in term of the individual legs),
> would it make sense to reuse the path protection mechanisms to tie those
> multiple EROs together? In addition it addresses the backup path already.
>
> [TS]: Consider the case of a PCE delegated SR Policy Candidate Path. The
> PCC desires an SR path computation from a PCE that is subject to
> constraints – The PCC has no a-priori idea **how many** Segment-Lists (SLs)
> the PCE path computation will result in-- so it does not know how many (or
> whether it should at all) create multiple PLSPs with NO-ERO and report them
> so PCE can respond to each.
>

The PCC can use a PCReq, PCRep, that allows multiple ERO. What is the
drawback of delegating the maximum set of Supported Segment List with no
ERO, the association may carry an attribute to indicate to the PCE
"Minimize the number of LSP with route" (or it can be a METRIC). The PCC
knows how many segment-list per candidate path are supported though
(whereas the PCE does not a priori)


> The PCC creates **one** PLSP and reports to the PCE the LSP down (with
> NO-ERO) along with the specified user constraints. The PCE computes and
> determines the feasible number of SLs. Now, it would be awkward for the PCE
> to instantiate PLSPs – different from the one originally delegated by the
> PCC—so to encode each SL in its own PLSP and make use the “association
> object” method.. I can also imagine complexities in what each PLSP LSP
> would carry in terms of constraints – especially after some configuration
> change on the PCC…
>

s/one/all/ and that works with:
  - limited extensions
  - reuse the path protection for protection
  - Any OAM extension and procedure works (as its per path)
  - The PCC has the freedom to have policies for per (set of) segment-list
constraints
  -

The function desired is more the shared control of the number of path
between the PCC and the PCE. Stateless PCE uses the LOAD-BALANCING for
that, but stateful has a more restrictive definition.
A possibility is to reuse the original multiple ERO defined, What is
currently a TE-Path, but adapt it to stateful:
   - allow LOAD-BALANCING (please refer to RFC5440) in PCRpt
   - the PCE May use multiple ERO and LOAD-BALANCING to *suggest* some
alternative paths to the PCC, in case of a candidate path the PCC should
create the other PLSPs
   - The PCE can update the LOAD-BALANCING and suggested ERO, the PCC
should update its set of LSPs

It keeps the PCE-Controlled number of paths, it can work for other kind of
associations that groups traffic together (RSVP, GMPLS) , you can keep OAM
and constraints freedom, scenarios like per-destination or region-chain PCE
delegation is still allowed
The PCC can have more control and options, or keep one LSP with
LOAD-BALANCING + candidate path


>
> The proposal in draft-koldychev-pce-multipath indeed proposes elegant way
> to encode all computed SLs (as multiple SERO lists) into a single PLSP –
> the one originally reported by the delegated PLSP. In fact, this method
> allows at anytime the PCE to send PCUpd to add/remove/update SL(s) within a
> single PLSP freely – which IMO is powerful.
>

I understand that people like to map their management objects directly,
but Its awkward to say that one path is not one path, Anyhow in term of TE
and OAM, each segment-list is kind of independent.
PCCreate works equally well for a PCE to create/delete paths, the
LOAD-BALANCING and suggested EROs offer more flexibility from PCE and PCC.



>
>
> I think the same argument applies to backup paths/SLs too.. The PCC would
> not know how many SL(s) can protect a single path, so it would not be able
> to a-priori create PLSPs and use association object.
>
>
> Where is the requirement of updating all the segment-list of an
> SR-Candidate together coming from?
>
>
>
> On an unrelated note, why is it called Candidate-path and not
> candidate-multipath, if there are multiple path?
>
>
>
> [TS]: please refer to draft-ietf-spring-segment-routing-policy which
> defines such terms…
>
>
>
The draft does not say why its considered a single path when it has
multiple physical paths,  nor the use of association with multiple PLSP
contradict contradict the unit of signaling (the unit of signaling being
the association parameters) .
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Multipath / replication segment comment

[Cyril Margaria]

Please see inline

On Thu, 19 Dec 2019 at 17:19, Stone, Andrew (Nokia - CA/Ottawa) <
andrew.st...@nokia.com> wrote:

> Few comments below,
>
> Cheers
> Andrew
>
> On 2019-12-19, 6:52 AM, "Dhruv Dhody"  wrote:
>
> Hi Andrew,
>
> Speaking as a WG contributor...
>
> On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa)
>  wrote:
> >
> > Hi all,
> >
> >
> >
> > In Singapore I made a remark about draft-koldychev-pce-multipath
> that it’s a helpful draft and is also applicable to the replication segment.
> >
> >
> >
> > I received a follow up question emailed directly, asking about
> whether “EROs need to share same source and destination” and how/if this
> could be related to RFC 8623.
> >
> >
> >
> > For openness, sending my thoughts/comments here to the WG:
> >
> >
> >
> > There is no requirement listed in draft-koldychev-pce-multipath that
> I can see which requires EROs to terminate on the same source/destination,
> I haven’t seen that expectation anywhere, and in my opinion there should
> not be.
>
> [Dhruv] You are right, this is not explicit in the I-D. But based on
> the scope of past discussion IMHO it was always about multiple paths
> (ERO) for a single tunnel and thus finding a way to encode them within
> a single report/update in a PCEP message.
>
> [Andrew] True, the original intent of multiple paths within the same
> tunnel in a single report/update, but that could still be leveraged in the
> replication case, i.e I want a single report/update to modify the state of
> a replication segment. I think it becomes a gray area in interpretation of
> whether or not a replication segment creates a P2MP tunnel or if it's
> actually just creating multiple P2P tunnels from a single ingress label. If
> the interpretation is it's a P2MP tunnel, then using multiple EROs to
> define the forwarding of a P2MP. Tunnel requires those EROs to terminate on
> different nods.
>
> [Cyril] There is a related work that ties one tunnel to multiple path,
list of hops :  RFC8697, and draft-ietf-pce-stateful-path-protection-11.
Given the mechanism used (and flexibility in term of the individual legs),
would it make sense to reuse the path protection mechanisms to tie those
multiple EROs together? In addition it addresses the backup path already.

Where is the requirement of updating all the segment-list of an
SR-Candidate together coming from?

On an unrelated note, why is it called Candidate-path and not
candidate-multipath, if there are multiple path?


> The new ERO-ATTRIB object in the I-D is just a separator between
> several ERO objects in a existing PCEP message which reports/update a
> particular LSP (identified by PLSP-ID in the LSP object).
>
> > For example, one of the use cases of draft-koldychev-pce-multipath
> is for SR Policy to support multiple SID lists, combine that with use case
> such as SR-EPE, you could have multiple SID lists and have weighted ECMP
> traffic out different egress nodes intentionally to load balance across
> different peer nodes.
>
> [Dhruv] As per the SR policy as it is currently defined - End point is
> the property of the SR Policy. Each segment-list inside a candidate
> path would be a specific source-routed path from the headend to the
> endpoint of the corresponding SR policy. That said, in this use case
> perhaps you would use an anycast address but still the same endpoint
> from the SR policy point of view.
>
>
> [Andrew] Coincidentally this was just mentioned in SPRING mailing list,
> whether in SR Policy endpoint is the tunnel termination vs a prefix/route
> to reach (which I kind of have to agree with), which seemed to have been
> raised because there's the concept of null/0.0.0.0 (and some wording on
> whether or not this is a valid "endpoint"). Anyways, in an EPE case I don't
> need to specify a path to reach the absolute endpoint, I just need to
> specify a path to steer to an egress peer, and with last label in the stack
> being an EPE Peer link or node, and that egress peer can take over the
> packet (likely not MPLS encaped anymore) and steer, forward or tunnel
> however it chooses. In this regard the SID list specified on the headend SR
> Policy "stops early" before the "real endpoint". From this perspective
> whether my ECMP SID lists stop on different routers or not is not really
> relevant for reaching the "real endpoint". Section 4.7 in
> draft-ietf-spring-segment-routing-central-epe-10 briefly comments on this,
> in the sense that to reach an internet route a SID list comprised of only
> SID(s) to reach the border node, and a SID to specify the peering router is
> sufficient. In this regard the path terminates on the peering router,
> despite the fact that my endpoint is much further in the network / perhaps
> across the internet.
>
>
> > Another example, with ingress replication, is the multipath ERO can
> 

Re: [Pce] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14

[Cyril Margaria]

Thanks for the review,

a new version has been posted addressing your comments.
Please also see inline

On Wed, 10 Apr 2019 at 13:47, Elwyn Davies via Datatracker 
wrote:

> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-pce-gmpls-pcep-extensions-14
> Reviewer: Elwyn Davies
> Review Date: 2019-04-10
> IETF LC End Date: 2018-10-29
> IESG Telechat date: 2019-04-11
>
> Summary:
> Almost ready, but with a large collection of nits in language and
> non-expansion
> of abbreviations. I am also concerned about the specification of behaviour
> in
> case PCC/PCEs with and without the extensions attempt to interact.  The
> requirements and behaviour are rather woolly, and are not fully covered by
> capability negotiations as the negotation capability itself is not in the
> original PCEP specification.
>
> Major issues:
> None
>
> Minor issues:
> Interacting with PCCs that do not support these GMPLS extensions: The
> draft is
> not very clear on interactions between PCCs that do support the extensions
> and
> ones that do not.  It is unclear whether a PCC that proposes to use the
> extensions must support the RFC 5088 or 5089 capability negotiation
> extensions
> and use them to determine if a PCEP exchange can use the extensions.  The
> text
> in para 1 of s2.1.2 appears to require that a node that does not support
> RFC
> 5088 or 5089 still has to understand that it has received the
> GMPLS-CAPABILITY
> type indicator and indicate a mismatch.  It seems to me that some
> additional
> explanation is needed to describe how mismatched PCC/PCEs understand the
> problem and deal with cases where a message with the new extensions is
> received
> (and presumably rejected) by a node that does not implement the extensions.
>
> [MC] The IGP-based discovery (RFC 5088 or 5089) are optional, and are
not capability negotiations. The Capability negotiation is done only
in PCEP, and the GMPLS-CAPABILITY TLV must be present from both peers
in order to make use of the extensions


> s9.2, RFC7025: Given the references to the requirements document for this
> work,
> I would consider RFC 7025 to be normative.
>
> [MC] 7025 is marked as Informational, so I am not sure it should
listed as normative.


> Nits/editorial comments:
>

[MC] All the nits have addressed


> General: s/e.g. /e.g., /g
>
Abstract: s/The Path Computation Element (PCE)/A Path Computation Element
> (PCE)/
>
> s1: Expand abbreviations OTN (Optical Transport Networks) and WSON
> (Wavelength
> Switched Optical Networks).
>
> s1, para 2: s/considered/addressed/, s/those application/these
> applications/
>
> s1.2, para 1: s/PCEP extension/PCEP extensions/, s/broken down in/broken
> down
> into/
>
> s1.2: Expand following acronyms/abbreviations on first occurrence: LSP,
> TE-LSP,
> L2SC, TDM, SONET, SDH, LSC [Query: Is LSC different from L2SC?], PCC, ERO
>
> s1.2, bullet 2: A reference for the G.709 standard is needed.
>
> s1.2 and s1.3.1, items (4) and (5): There doesn't seem to be a definition
> of
> Concatenation Number in any of the documents mentioned here or anywhere on
> the
> web.  I suspect it is supposed to be the number of streams that are
> concatenated but this needs to be properly defined or a reference provided.
>
> s1.2, bullet 5:  s/Label restriction/label restriction/.  I take it this
> refers
> to the use of Label Set objects as described in RFC 3473.  If so please
> add a
> reference.  If not lease provide the appropriate reference.
>
> s1.3.1: Expand following acronyms/abbreviations on first occurrence:
> TE-LSP,
> ODU, IRO, XRO, RRO, LSPA
>
> s1.3.1, item (4): s/Its scoped/It is scoped/ [English language note: 'Its'
> is
> the possessive pronoun derived from the third person singular impersonal
> pronoun 'it', whereas "It's" is a contraction of 'it is' that is not
> normally
> used in formal documents.]
>
> s1.3.1, item (4):
>
> > related to the BANDWIDTH object in MPLS networks
> I assume this relates to the BANDWIDTH object in RFC 5440 - please add a
> reference.
>
> s1.3.2, item (1):  The previous two comments on s.1.3.1, item (4) apply
> also to
> this item.
>
> s1.4:
>
> OLD:
>
>  1.4   GMPLS Support and Limitation of Base PCEP Objects
>
>The support for requirements [RFC7025] is summarized in Table 1 and
>Table 2
>
> NEW:
>
> 1.4   Existng Support for GMPLS in Base PCEP Objects and its Limitations
>
>The support provided by specifications in [RFC8282] and [RFC5440]  for
> the
>requirements listed in [RFC7025] is summarized in Table 1 and Table 2.
> In
>some cases the support may not be complete, as noted, and additional
> 

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

[Cyril Margaria]

Thanks for the thorough review, a new version addressing the comments has
been posted,

please see inline

A new version

On Thu, 11 Apr 2019 at 12:46, Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-pce-gmpls-pcep-extensions-14: Discuss
>
> 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-gmpls-pcep-extensions/
>
>
>
> --
> DISCUSS:
> --
>
> This document makes some well-needed extensions to existing PCEP
> concepts such as bandwidth, but I'm not convinced that the way they
> interact with existing PCEP functionality is sufficiently well specified
> to admit interoperable implementation.  Specifically, we introduce the
> generalized bandwidth structures and reuse that encoding for the
> generalized load balancing structures, which includes a notion of
> "minimum bandwidth specification".  But now that the bandwidth
> specification is a compound data structure instead of a scalar type,
> it's not guaranteed that we have a strict linear ordering with
> well-defined minimum.  If we consider the specific case of Intserv, do I
> insist upon all three of the minimum bucket rate, minimum bucket size,
> and minimum peak data rate?  Or perhaps I only care about the peak data
> rate and not the bucket size/rate.  We need more text in order to
> specify what "minimum" actually means/measures.
>
> Similarly, I'm not sure all the referenced generalized bandwidth
> types/traffic parameters in Section 2.3 clearly indicate which
> structures/fields we are to incorporate by reference (see COMMENT).
>
>
[MC] Thanks Julien for the text that was agreed on; it has been
incorporated in the new version.

OLD
   The semantic of the LOAD-BALANCING object is not changed.  If a PCC
   requests the computation of a set of TE-LSPs so that the total of
   their generalized bandwidth is X, the maximum number of TE-LSPs is N,
   and each TE-LSP must at least have a bandwidth of B, it inserts a
   BANDWIDTH object specifying X as the required bandwidth and a LOAD-
   BALANCING object with the Max-LSP and Min Bandwidth Spec fields set
   to N and B, respectively.

NEW
   The semantic of the LOAD-BALANCING object is not changed.  If a PCC
   requests the computation of a set of TE-LSPs with at most N TE-LSPs
   so that it can carry generalized bandwidth X , each TE-LSP must at
   least transport bandwidth B, it inserts a BANDWIDTH object specifying
   X as the required bandwidth and a LOAD-BALANCING object with the Max-
   LSP and Min Bandwidth Spec fields set to N and B, respectively.  When
   the BANDWIDTH and Min Bandwidth Spec can be summarized as scalars,
   the sum of all TE-LSPs bandwith in the set is greater than X.  The
   mapping of X over N path with (at least) bandwidth B is technology
   and possibly node specific.  Each standard definition of the
   transport technology is defining those mappings and are not repeated
   in this document.  A simplified example for SDH is described in
   Appendix A


   In all other cases, including for technologies based on statistical
   multiplexing (e.g., InterServ, Ethernet), the exact bandwidth
   management (e.g., Ethernet's Excessive Rate) is left to the PCE's
   policies, according to the operator's configuration.  If required,
   further documents may introduce a new mechanism to finely express
   complex load balancing policies within PCEP.



> Section 2.1.2 says:
>
>GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use
>of the objects and TLVs defined in this document.
>
> Why is this not "the PCC MUST NOT make use of the objects and TLVs
> defined in this document"?  Ignoring the peer's (non-)advertisement and
> plowing ahead seems like a recipe for non-interoperability.
>
>

[MC] The PCC is able to mandate or not the processing of objects on
per-request basic. To make it simpler the capability negotiation has
been made mandatory (both peer must advertize the capability).


Section 2.5.1 notes that:
>
>   ::=
> []
>[ []]...
>
>
>For endpoint type Point-to-Multipoint, several endpoint objects MAY
>be present in the message and each represents a leave, exact meaning
>depend on the endpoint type defined of the object.
>
> If all s represent leaves, then how is the head node
> specified?
>
>
[MC] In case of P2P the first endpoint is the ingress and the second is
egress.
In case of P2MP, the first endpoint is root and 

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Cyril Margaria]

Hi Mike,

One of my point is that one optimization is a peculiar case of n
optimization. For the particuliar case of candidate path, it can be
attached to a given association, each TE-LSP can have the same optimization
criterias.

I understand the argument for Option 2 as "I want to carry and manage my
constraint  (and candidate path) as one PCEP entity", the drawback is that
it will become complicated in case of inter-domain and OAM which are per
path.
The case for option 1 is one path, one LSP, but as you pointed out it
becomes complicated when there is one candidate path that desire a behavior
similar to  LOAD-BALANCING where the PCC ask the PCE to decide how many
path are needed.

I think that option 1 is better in term of protocol reuse and will offer
more flexibility, but that depends on how to deal with the PCE-managed
number of paths.

I will not attend the IETF meeting,

Best regards,
Cyril



On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) 
wrote:

> Hi Cyril,
>
>
>
> Thanks a lot for your feedback!
>
>
>
> Maybe I need to make it clear that the problem we’re trying to solve is a
> single optimization objective resulting in multiple ECMP/UCMP paths. This
> is motivated by SR-TE Policy use case, where each Candidate Path represents
> a single optimization objective. The Candidate Path has a set of Segment
> Lists that satisfy the optimization objective.
>
>
>
> You seem to want to solve a different problem: two or more different
> optimization objectives and each ECMP path is mapped to a different
> objective. In that case Solution 1 is absolutely necessary and it would not
> have any of the down-sides, because the PCC knows in advance how many
> optimization objectives it has and can create that many PCEP LSPs. However
> for our problem, Solution 1 would introduce a lot of implementation
> complexity and protocol overhead.
>
>
>
> We have a side-meeting scheduled on Wednesday at 8:30 to discuss this
> topic, you are welcome to attend if you want to contribute your input.
>
>
>
> Thanks,
>
> Mike.
>
>
>
> *From:* Cyril Margaria 
> *Sent:* Friday, July 19, 2019 9:37 AM
> *To:* Mike Koldychev (mkoldych) 
> *Cc:* pce@ietf.org
> *Subject:* Re: [Pce] Proposal for signaling ECMP or UCMP paths
>
>
>
> Hi,
>
>
>
> On slide "LSP objectives and constraints": Stateless  PCE can compute set
> of EROs/Label switch paths using RFC6007, including multi-domain and
> multi-PCEs scenarios. This can be used for computing a set of EROs for SR
> candidate paths, one case that can apply to the candidate path and
> explicitly mentioned by the RFC is "Two or more end-to-end diverse
> paths".  This does not cover the stateful PCE case directly, but there are
> similar situations to what RFC6007 in the form of path protection
> (primary/secondary/standby) for statefull PCE, which use the association
> mechanism. Those two existing mechanism exists to coordinate several paths
> and could be used to indicate how multiple paths are related and on how to
> signal them together (SVEC)
>
>
>
> On slide "Analysis of Solution 1":
>   - For PCC-Initated LSPs: what prevents the PCE to to create
> PCE-Initiated LSPs using the same association id? This would tackle the
> problem.
>
>   - The possibility of each path to have different objective does seems to
> be an advantage as its less restrictive. Having the same restriction on a
> set of paths is easy, relaxing a restriction on the ERO #5 is more
> complicated (in term of encoding).
>   - There is a set of options to achieve the "signal the set of paths
> together":
>  a)  set of LSPs can be reported in the same message, it can be
> enforced by the document defining that specific association type.
>
>  b) SVEC/SVEC List can be extended to statefull PCEP,
>
>
> That solution would work in case of multi-domain PCEs, and also be helpful
> for OAM and auto-bw mechanism.
>
> As a segment list is one path in the network, that maps nicely to one LSP..
>
>
>
>
>
> Solution 2:
>
>   - This limit the set of constraints to be applied, policies like "10% of
> the traffic does not need to be protected" cannot be expressed (it can be
> with solution 1, clear L bit of LSPA on one TE-LSP out of 10)
>
>   - 2.a when the LSP is reported down : which ERO is down?, the same is
> applicable for auto-bw and any form of OAM data.
>
>   - Solution 2.b allows for Optimized branch encoding, that should be
> disabled for that solution
>
>
>
>
>
> Slide "Comparison of Solutions":
>
>- There are solutions to most of the points raised for solution 1
>
>- The database problem seems specific to

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Cyril Margaria]

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set
of EROs/Label switch paths using RFC6007, including multi-domain and
multi-PCEs scenarios. This can be used for computing a set of EROs for SR
candidate paths, one case that can apply to the candidate path and
explicitly mentioned by the RFC is "Two or more end-to-end diverse paths".
This does not cover the stateful PCE case directly, but there are similar
situations to what RFC6007 in the form of path protection
(primary/secondary/standby) for statefull PCE, which use the association
mechanism. Those two existing mechanism exists to coordinate several paths
and could be used to indicate how multiple paths are related and on how to
signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated
LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to
be an advantage as its less restrictive. Having the same restriction on a
set of paths is easy, relaxing a restriction on the ERO #5 is more
complicated (in term of encoding).
  - There is a set of options to achieve the "signal the set of paths
together":
 a)  set of LSPs can be reported in the same message, it can be
enforced by the document defining that specific association type.
 b) SVEC/SVEC List can be extended to statefull PCEP,

That solution would work in case of multi-domain PCEs, and also be helpful
for OAM and auto-bw mechanism.
As a segment list is one path in the network, that maps nicely to one LSP.


Solution 2:
  - This limit the set of constraints to be applied, policies like "10% of
the traffic does not need to be protected" cannot be expressed (it can be
with solution 1, clear L bit of LSPA on one TE-LSP out of 10)
  - 2.a when the LSP is reported down : which ERO is down?, the same is
applicable for auto-bw and any form of OAM data.
  - Solution 2.b allows for Optimized branch encoding, that should be
disabled for that solution


Slide "Comparison of Solutions":
   - There are solutions to most of the points raised for solution 1
   - The database problem seems specific to one implementation, other
implementation will have the problem for solution 2
   -  multi-PCE and multi-domain are not evaluated. Solutions and
consideration are available for solution 1, not for solution 2.
(experimental Inter-domain P2MP tree solutions exists).

Best Regards,
Cyril

On Fri, 12 Jul 2019 at 22:02, Mike Koldychev (mkoldych) 
wrote:

> Hi WG,
>
> As per SPRING WG, SR Policy may contain multiple Candidate Paths and each
> Candidate Path may contain multiple Segment Lists. Existing SR standards in
> PCEP allow only a single ERO (one Segment List) for the SR Path in a
> stateful PCEP message. There is a need to signal multiple Segment Lists in
> PCEP for this as well as other load balancing use cases.
>
> See the link that describes this, as well as list possible ways to achieve
> this. Please provide your feedback on the list or during the WG session.
>
> https://github.com/dhruvdhody-huawei/105/blob/master/multiple_ERO_jl03a.pdf
>
> Thanks,
> Mike.
>
> ___
> 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] Suresh Krishnan's No Objection on draft-ietf-pce-gmpls-pcep-extensions-14: (with COMMENT)

[Cyril Margaria]

Thanks for the review,

please see inline

Best regards,
Cyril Margaria


On Tue, 9 Apr 2019 at 20:41, Suresh Krishnan via Datatracker <
nore...@ietf.org> wrote:

> Suresh Krishnan has entered the following ballot position for
> draft-ietf-pce-gmpls-pcep-extensions-14: 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-gmpls-pcep-extensions/
>
>
>
> --
> COMMENT:
> --
>
> * Section 2.5.2
>
> "In this object type the order of the TLVs MUST be followed according to
> the
> object type definition."
>
> Not sure what this means. Can you clarify?
>
>
[MC] This refers to Section 2.5.1 Generalized Endpoint Object Type,
the TLV ordering matters (for a given object type).
A better wording could be as follows:
NEW:
All endpoint TLVs have the standard PCEP TLV header as defined in
   [RFC5440] section 7.1.  For the Generalized Endpoint Object Type the
   TLVs MUST follow the ordering defined in Section 2.5.1.


> * Section 2.7
>
> "C-Type (8 bits): the C-Type of the included Label Object as defined in
> [RFC3471]."
>
> I could not find any references to C-Types in RFC3471. Shouldn't you be
> referring to RFC3473 instead? I have a similar comment for the Label field.
>
>
[MC] The reference should indeed be RFC3473 for the C-Type. The Label field
is technology-dependent and defined in RFC3471, the per-technology labels
are defined in the technology-specific RFCs.



>
> ___
> 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] Roman Danyliw's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

[Cyril Margaria]

Thanks for the review, please see inline

Best Regards,
Cyril

On Thu, 11 Apr 2019 at 00:13, Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-gmpls-pcep-extensions-14: Discuss
>
> 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-gmpls-pcep-extensions/
>
>
>
> --
> DISCUSS:
> --
>
> (1) Section 6, Per “The answer can make that the LSP traverses some
> geographical place known to the attacker where some sniffing devices could
> be
> installed”, this is a concern.  Good that it is here.  However, it seems
> like
> the consequences could be even more expansive – confidentiality (sniffing),
> integrity (modifying the traffic) or availability (choose to drop it).
>
>
Would the following change cover those consequences:

NEW:
  PCE Identity theft: A legitimate PCC could request a path for a
  GMPLS LSP to a malicious PCE, which poses as a legitimate PCE.
  The answer can make that the LSP traverses some geographical place
  known to the attacker where confidentiality (sniffing), integrity
  (traffic modification) or availability (traffic drop) attacks
  could be performed by use of an attacker-controlled  device.


(2) Section 6, [RFC8253] is mentioned a few times as having a variety of
> capabilities to mitigate the described threats.  This is the right
> reference.
> However, the current text doesn’t explicitly state whether and how this
> guidance should be followed (should, must, is recommended?)
>
>
>
Would the following be appropriate?

NEW:
  The document [RFC8253] describes the usage of Transport Layer
   Security (TLS) to enhance PCEP security.  The document describes the
   initiation of the TLS procedures, the TLS handshake mechanisms, the
   TLS methods for peer authentication, the applicable TLS ciphersuites
   for data exchange, and the handling of errors in the security checks.
   PCE and PCC SHOULD use [RFC8253] mechanism to protect against
   malicious PCC and PCE.




> --
> COMMENT:
> --
>
> (1) Section 2.3, Nit (missing commas and periods),
> s/(SDH/SONET, G.709, ATM, MEF etc)/
> (SDH/SONET, G.709, ATM, MEF, etc.)/
>
> (2) In a few section.  Typo (duplicate “section Section”)..  Recommend
> global
> s/section Section/Section/g
>
>
Thanks for catching those, I did not find the duplicated against though.


> (3) Section 6.  Duplicate word.  s/against against/against/
>
>
>



> ___
> 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] Updates on draft-ietf-pce-gmpls-pcep-extensions-14.txt

[Cyril Margaria]

Dear PCEers,


A new version of the drat has been posted, it contains a few edits noted by our 
new chair (Dhruv). Those edits are made to align with issues raied by IESG 
during the review of https://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-17.


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

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

[Cyril Margaria]

Hi,

This update addresses my comments, including the recommended capability
advertisement.

Thanks,
Cyril

On 6 September 2018 at 01:39, Julien Meuric 
wrote:

> Hi all,
>
> I have not seen any feedback on the update below. We will thus consider
> that everyone is fine with the optional advertisement which has been added.
>
> Cyril, you raised the issue: could you please confirm this update
> addresses your comment?
>
> Thanks,
>
> Julien
>
>
> Jun. 19, 2018 - Dhruv Dhody:
>
> Hi WG,
>
> We have posted an update to the association group draft that handle the
> final pending issue regarding capability advertisement.
> See the update - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-
> association-group-06
>
> Hope the document can be sent to IESG soon!
>
> Thanks!
> Dhruv
>
> On Thu, Apr 26, 2018 at 4:33 PM Dhruv Dhody 
> wrote:
>
>> Hi Cyril,
>>
>>
>>
>> Thanks for engaging, please see inline *[[Dhruv Dhody2]]*
>>
>>
>>
>> Working Copy:
>>
>> Diff: https://tools.ietf.org/rfcdiff?url1=https://tools.
>> ietf.org/id/draft-ietf-pce-association-group-05.txt=
>> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
>> master/draft-ietf-pce-association-group-06.txt
>> <https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-05.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-06..txt>
>>
>> Txt: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-
>> ietf-pce-association-group-06.txt
>>
>>
>>
>>
>>
>> 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
>>
>> [image: Huawei-small]
>>
>> 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!
>>
>>
>>
>> *From:* Cyril Margaria [mailto:cyril.marga...@gmail..com
>> ]
>> *Sent:* 26 April 2018 00:13
>> *To:* Dhruv Dhody 
>> *Cc:* LITKOWSKI Stephane DTF/DERX ; Dhruv
>> Dhody ; pce@ietf.org
>> *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group
>>
>>
>>
>> Hi,
>>
>>
>>
>> Thanks for the prompt reply, sorry for the not-so-prompt handling of that.
>>
>> Please see inline
>>
>>
>>
>> On 23 February 2018 at 08:51, Dhruv Dhody  wrote:
>>
>> Hi Cyril,
>>
>>
>>
>> Thanks for your review and suggestions. I could not get to this earlier,
>> apologies for that! Please see inline...
>>
>>
>>
>> Diff: https://tools.ietf.org/rfcdiff?url1=https://tools.
>> ietf.org/id/draft-ietf-pce-association-group-04.txt=
>> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
>> master/draft-ietf-pce-association-group-05.txt
>> <https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-pce-association-group-04.txt=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-association-group-05..txt>
>>
>> Txt: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-
>> ietf-pce-association-group-05.txt
>>
>>
>>
>> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
>> *Sent:* 02 February 2018 04:54
>> *To:* LITKOWSKI Stephane DTF/DERX 
>> *Cc:* pce@ietf.org
>> *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group
>>
>>
>>
>> Hi,
>>
>>
>>
>> I support the feature, I have the following comment regarding the draft:
>>
>>   - There is not mandated capability negotiation, this generally makes
>> interworking more cumbersome.
>>
>>   This could be resolved by mandating the presence of  OP-CONF-ASSOC-RANGE,
>> and using reserved value 0,0 for  Start-Assoc-ID, Range to indicate that
>> there is no
>>
>> Operator-configured Association Range.
>>
>>
>>
>&

Re: [Pce] draft-ietf-pce-gmpls-pcep-extensions

[Cyril Margaria]

I started to process the comments, I will distribute a draft by tomorrow.


From: Leeyoung 
Sent: Tuesday, July 24, 2018 10:28:45 AM
To: Cyril Margaria
Cc: pce-cha...@ietf.org; pce@ietf.org
Subject: draft-ietf-pce-gmpls-pcep-extensions


Hi Cyril,



We are waiting for the update of the draft-ietf-pce-gmpls-pcep-extensions. What 
is your plan for this draft? Please let us know if you have time to update this 
draft within a few week; otherwise send me the original file so that I can help 
update the draft.



Thanks & Best regards,

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

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

[Cyril Margaria]

Hi,

Thanks for the prompt reply, sorry for the not-so-prompt handling of that.
Please see inline

On 23 February 2018 at 08:51, Dhruv Dhody <dhruv.dh...@huawei.com> wrote:

> Hi Cyril,
>
>
>
> Thanks for your review and suggestions. I could not get to this earlier,
> apologies for that! Please see inline...
>
>
>
> Diff: https://tools.ietf.org/rfcdiff?url1=https://tools.
> ietf.org/id/draft-ietf-pce-association-group-04.txt=
> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/
> master/draft-ietf-pce-association-group-05.txt
>
> Txt: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-
> ietf-pce-association-group-05.txt
>
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
> *Sent:* 02 February 2018 04:54
> *To:* LITKOWSKI Stephane DTF/DERX <stephane.litkow...@orange.com>
> *Cc:* pce@ietf.org
> *Subject:* Re: [Pce] WG LC of draft-ietf-pce-association-group
>
>
>
> Hi,
>
>
>
> I support the feature, I have the following comment regarding the draft:
>
>   - There is not mandated capability negotiation, this generally makes
> interworking more cumbersome.
>
>   This could be resolved by mandating the presence of  OP-CONF-ASSOC-RANGE,
> and using reserved value 0,0 for  Start-Assoc-ID, Range to indicate that
> there is no
>
> Operator-configured Association Range.
>
>
>
> *[[Dhruv Dhody]] The presence of ASSOCIATION object in PCEP message is a good 
> indicator for this feature. Not sure if there is a need to exchange 
> capabilities in OPEN, we have followed the similar approach in RFC5455, 5520, 
> 5521 etc.  *
>
>  [MC] Peer capability discovery is supported in RFC5541, RFC8281,
RFC6006. The ability to know which type of association (bidirectional LSP,
path protection,..etc) is supported affect the Path Computation,
   and in addition the reception of an unknown object will close the
session, which is less than ideal at scale.
 If the  OP-CONF-ASSOC-RANGE is not meaningful, then a TLV for discovery is
needed (list of association source and reserved flags for draft use would
be ideal)

Section 4.1 : what happens if the dynamic allocation ranges do not
match between the two peer ? is it allowed or should the session be
bounced?
>
>   A special case can be made when one peer advertise (0,0)
>
>
>
> *[[Dhruv Dhody]] I have added an appendix with an example to make this 
> clearer, please let me know if I need to make any change for this! *
>
>
>
> The example helps, maybe the following change in version 5, section 3.4
would clarify further:
OLD:

   A range of association identifier for each association-type are kept
   for the operator-configured associations.  Dynamic associations MUST
   NOT use the association identifier from this range.

   This range as set at the PCEP speaker (as an association source)
   needs to be communicated to a PCEP peer in the Open Message.  A new
   TLV is defined in this specification for this purpose (Section 4
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#section-4>).
   See Appendix A
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#appendix-A>
for an example.

NEW:

   A range of association identifier for each
association-type,association-source are kept
   for the operator-configured associations.  Dynamic associations MUST
   NOT use the association identifier from this range.

   This range as set at the PCEP speaker (PCC or PCE) and
   needs to be communicated to a PCEP peer in the Open Message.  A new
   TLV is defined in this specification for this purpose (Section 4
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#section-4>).
   See Appendix A
<https://tools.ietf.org/html/draft-ietf-pce-association-group-05#appendix-A>
for an example.


   Association identifier range for sources other than the PCEP peer
(an NMS system for example) is outside the scope of this document,

--





> section 5.2.1:
>
>  - the PCC can remove an association by setting the R flag to 1, if the PCC 
> does not include any association, should the association be kept on the LSP?
>
> *[[Dhruv Dhody]] The R flag is set in association, if association id is zero, 
> that is invalid; if association id is 0x, then it is all association 
> within the scope of association type/source; otherwise it looks for 
> association, if not found it is considered as unknown association. *
>
>
So


>  - I think the following should be added : PCRpt: all associations MUST be 
> reported during state synchronization
>
> *[[Dhruv Dhody]] Ack. *
>
>  - Value 0 was previously used to ask a peer to allocate an association ID. 
> Is it deemed not necessary anymore.
>
> *[[Dhruv Dhody]] Yes*
>
>
>
>
>
> Section 5.3:
>
> 

Re: [Pce] 答复: WG adoption poll for draft-li-pce-pcep-flowspec-03

[Cyril Margaria]

Yes/Support .




On 23 February 2018 at 00:51, Aijun Wang  wrote:

> Yes/Support
>
>
>
> *发件人:* Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> *发送时间:* 2018年2月20日 21:34
> *收件人:* pce@ietf.org
> *抄送:* draft-li-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org
> *主题:* [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03
>
>
>
> Dear PCE WG
>
>
>
> This is the start of a two week poll on making
> draft-li-pce-pcep-flowspec-03 a PCE working group document.
>
> https://datatracker.ietf.org/doc/draft-li-pce-pcep-flowspec/
>
>
>
> Please review the draft and send an email to the list indicating
> “yes/support” or “no/do not support”.  If indicating no, please state your
> reasons.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
>
>
> The poll ends on Tuesday, March 6.
>
>
>
> Many thanks,
>
>
>
> Jon and Julien
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Cyril Margaria]

Hi,

I support the feature, I have the following comment regarding the draft:
  - There is not mandated capability negotiation, this generally makes
interworking more cumbersome.
  This could be resolved by mandating the presence of  OP-CONF-ASSOC-RANGE,
and using reserved value 0,0 for  Start-Assoc-ID, Range to indicate that
there is no

Operator-configured Association Range.


Section 4.1 : what happens if the dynamic allocation ranges do not
match between the two peer ? is it allowed or should the session be
bounced?

  A special case can be made when one peer advertise (0,0)



section 5.2.1:

 - the PCC can remove an association by setting the R flag to 1, if
the PCC does not include any association, should the association be
kept on the LSP?

 - I think the following should be added : PCRpt: all associations
MUST be reported during state synchronization

 - Value 0 was previously used to ask a peer to allocate an
association ID. Is it deemed not necessary anymore.



Section 5.3:

 - the "association information" is not defined. The whole section can
be clarified by detailing what the association information is.:

is it (association type, association source, association-id), from the
association group definitions, the triplet defines a group, so it
should be possible to have several association id for th same type,
source


Does the the "association information previously received about the
same association from a peer" relates to the association group (should
there be an unique association id per lsp for a given type,source)

or does it refers to the optional TLVs.


"

   On receiving association
   information that does not match with the association information
   previously received about the same association from a peer, it MUST
   return a PCErr message with Error-Type TBD "Association Error" and
   Error-Value 6 "Association information mismatch""


This could be clarified, IMHO generally speaking the draft should
allow several association id per (type, source), this kind of
restriction may be defined in the documents defining the association
types.



Thanks, Cyril


On 1 February 2018 at 10:38,  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
>
> 
> _
>
> 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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Cyril Margaria]

Hi,

I have the following (hopefully not too late) comments/questions:

Section 5.3 ERO Object

 S: When this bit is set, the SID value in the subobject body is
 null.  In this case, the PCC is responsible for choosing the
 SID value, e.g., by looking up its TED using the NAI which, in
 this case, MUST be present in the subobject.


- What is the associated procedure if the PCC cannot resolve the NAI to a
SID? Should there be associated error codes. For instance the PCC may not
be able to resolve the NAI  at all or the resolution may fail. In case the
PCC does not support the NAI resolution, having this capability part of the
capability exchange would improve interop, as the PCE can be capable to
provide the SID.
- If Both S and F are cleared, should the PCC do the NAI resolution and
verify that the SID match? Would error codes be needed)

Thanks,
Cyril


On 30 January 2018 at 01:19, Dhruv Dhody  wrote:

> Hi,
>
>I had reviewed and given comments on the I-D in the past, which the
>authors had addressed. I found these additional nits/suggestions.
>Apologies for being late by a day.
>
>Suggestions
>---
>
>Section 1
>
>(1) Though it is true that a child PCE act as a PCC towards the
>parent PCE, I feel it is not wise to say the opposite, that is a PCC
>is acting as a PCE in this context. I see no advantage to bring up the
>H-PCE in this context. I suggest we remove it.
>
>   A PCE, or a PCC operating as a PCE (in hierarchical PCE
>   environment), computes paths for MPLS Traffic Engineering LSPs
>   (MPLS-TE LSPs) based on various constraints and optimization
>   criteria.
>
>(2) Since this document is related to MPLS data plane only, it would
>be nice to include a pointer to the SRv6 work in PCEP for the benefit
>of the readers.
>
>(3) Regarding first mention of PST
>OLD:
>   This specification relies on the procedures specified in [I-
>   D.ietf-pce-lsp-setup-type].
>NEW:
>   This specification relies on the procedures specified in [I-
>   D.ietf-pce-lsp-setup-type] for the path setup type for SR.
>
>Section 3
>
>(4) Regarding this text -
>
>   SR-TE LSPs
>   computed by a PCE can be represented in one of the following forms:
>
>   o  An ordered set of IP address(es) representing network nodes/links:
>  In this case, the PCC needs to convert the IP address(es) into the
>  corresponding MPLS labels by consulting its Traffic Engineering
>  Database (TED).
>
>   o  An ordered set of SID(s).
>
>   o  An ordered set of both MPLS label(s) and IP address(es): In this
>  case, the PCC needs to convert the IP address(es) into the
>  corresponding SID(s) by consulting its TED.
>
>Each SR-ERO object can include both SID and NAI (IP address); this
>case is different from the case 3 above, I suggest if some text can
>be added to make things clearer.
>
>Section 5.1.1
>
>(5) Why SHOULD in this text?
>
>   A PCEP speaker SHOULD indicate its support of the function described
>   in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
>   OPEN object with this new PST included in the PST list.
>
>Section 6
>
>(6) Regarding,
>
>   A PCEP speaker that does not support the SR PCEP capability cannot
>   recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a
>   PCEP error with Error-Type = 4 (Not supported object) and Error-Value
>   = 2 (Not supported object Type) as per [RFC5440].
>
>RFC 5440 did not state the behavior for unknown sub-object. My
>suggestion would be -
>
>   A PCEP speaker that does not support the SR PCEP capability and
>   thus cannot recognize the SR-ERO or SR-RRO subobjects, it will
>   respond according to the rules for a malformed object as per
>   [RFC5440].
>
>Section 7
>
>(7) Suggest to make Manageability Consideration section as per RFC
>6123
>
>(8) PCEP-Yang should be mentioned in section 7.2
>
>Section 8
>
>(9) Suggest we expand the security consideration section a bit based
>on recent DISCUSSes.
>
>
>Nits
>
>
>Section 5.3.1
>
>s/MUST not/MUST NOT/
>
>Section 5.3.3
>
>(2)
>OLD:
>   A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
>   PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
>   message and MUST send a PCErr message with Error-Type=3 ("Unknown
>   Object") and Error-Value=2 ("Unrecognized object Type") or Error-
>   Type=4 ("Not supported object") and Error-Value=2 ("Not supported
>   object Type"), defined in [RFC5440].
>NEW:
>   A PCEP speaker that does not recognize or support the SR-ERO
>   subobject in PCRep, PCInitiate, PCUpd or PCRpt messages MUST
>   reject the entire PCEP message and MUST send a PCErr message with
>   

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

[Cyril Margaria]

+1,

PCEP is rather efficient at dealing with paths and constraints.
PCE-CC , as someone mentioned earlier, can be seen as 1-hop LSPs, there
could be minimum protocol extensions.

PCEP-LS is redoing links-state flooding over PCEP, using the same elements
as existing protocols. This sounds OK as an experiment but the operational
or scale advantages to it seems very limited.

I don't think we should overload PCEP to carry IGP information (nor device
configuration)

My 2 cents
Cyril


On 24 July 2017 at 08:02,  wrote:

> Hi,
>
>
>
> As soon as we started with the active stateful PCE, the PCE became an SDN
> controller who takes decision and programs the network.
>
> So as many already mentioned, PCEP as an SBI is already done.
>
>
> IMO, PCECC does not change significantly PCEP, it’s just bring a new kind
> of LSP style for this hop by hop path programming. A controller
> implementing hop by hop path programming will require more intelligence as
> it needs to program nodes in the right order to prevent transient loops…
>
>
>
> The question is more what is the exact scope of PCEP in term of SBI and do
> we want to create a protocol that does everything , including coffee J ?
>
> We already have plenty of protocols: BGP, IGP, Netconf. Each protocol has
> strength and weaknesses and I’m not sure that we need to mimic all features
> in all protocols. What is the gain here ?
>
> The best approach may be to use strength of protocols and use them for
> what they are good for:
>
> Example:
>
> IGP has good flooding capability with “limited scale”: interesting when
> all receivers need the same information
>
> BGP has good flooding capability with large scale and ability to target
> specific groups (using route targets/communities) : interesting when groups
> of receivers need the same information
>
> Netconf more generic and point to point
>
> …
>
>
>
>
>
> IMO:
>
> do we need PCEP-LS ? => This can be discussed, we already have two
> protocols to exchange the topology…
>
> do we need to add configuration capabilities in PCEP => not sure, we have
> Netconf for that.
>
> Why not limiting PCEP to path programming and path policies (traffic
> steering on path…) ?
>
>
>
> Brgds,
>
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick
> *Sent:* Thursday, July 20, 2017 17:22
> *To:* pce@ietf.org
> *Cc:* pce-cha...@ietf.org
> *Subject:* [Pce] PCEP as an SDN controller protocol?
>
>
>
> Dear PCE WG
>
>
>
> The purpose of this email is to initiate a discussion about whether we
> want to extend PCEP to allow it to replace the functions that are
> traditionally provided by the routing and signalling protocols.
>
>
>
> Originally, PCEP was designed with the goal of providing a distributed
> path computation service.  In recent years we have extended that mission,
> and added path modification and path instantiation capabilities to PCEP.
> This has added capabilities to PCEP that would traditionally have been
> performed by the network management plane.
>
>
>
> We are now starting to discuss proposals to add more capabilities to PCEP
> – capabilities that are traditionally part of routing and signalling.
> There were three examples of this in the PCE working group meeting this
> week.
>
> ·The PCECC proposal, which extends PCEP’s path instantiation
> capability so that the PCE can provision a path end-to-end by touching each
> hop along the path.  This replaces the function already provided by RSVP-TE.
>
> ·The PCEP-LS proposal, which extends PCEP to allow link state and
> TE information to be communicated from the network to the PCE.  This
> replaces the link state flooding function provided by the IGPs, or BGP-LS.
>
> ·The PCECC-SR proposal extends PCEP to allow device-level
> configuration to be communicated between the network and the PCE, such as
> SRGBs, prefix SIDs etc.  Again, this replaces functions that are already
> designed into the IGPs.
>
>
>
> These proposals are taking PCEP in the direction of being a fully-fledged
> SDN protocol.  With these proposals, one can envision a network in which
> there is no traditional control plane.  PCEP is used to communicate the
> current network state and to program flows.  These proposals have their
> roots in the ACTN and PCECC architectures that are adopted within the TEAS
> working group.  TEAS is very much assuming that this is the direction that
> we want to take PCEP in.  However, there are two procedural issues, as I
> see it.
>
> 1.  We have not had an explicit discussion in the PCE WG about
> whether we want to take PCEP in this direction.  We have had a few lively
> debates on specific cases, like PCEP-LS, but those cases represent the
> “thin end of the wedge”.  If we start down this path then we are accepting
> that PCEP will replace the functions available in the traditional control
> plane.  We need to test whether there is a consensus in the working group
> to move in that 

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

[Cyril Margaria]

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

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

[Cyril Margaria]

Hi,

I think the text from Stephane solve well the no-path case, if a PCE would
like to force a tear-down of the LSP, the admin-status bit seems
appropriate.
In the case you mention, a PCE may sets a loose hop towards egress, but its
up to the PCC to expand or not the ERO.

BR
Cyril


On 11 October 2016 at 19:16, Sudhir Cheruathur 
wrote:

> Stephane/Dhruv/Xian,
>
>
>
> I am concerned with the need to revoke the delegation when there is no
> path. Today, we can change three attributes of a delegated LSP - Path
> (ERO), Bandwidth and Metric.
>
>
>
> Are we suggesting that when BW and/or Metric is changed it must always be
> accompanied with a path? How would you handle cases where only BW and/or
> Metric is changed for a delegated LSPs from controller that has no
> computation engine or would prefer the PCC to do the computation?  Yes,
> keep the existing path could be an option but since it is not always
> guaranteed we will need appropriate error handling.
>
>
>
> Thanks
>
> Regds
> Sudhir C
>
>
>
>
>
> *From: *Pce  on behalf of "
> stephane.litkow...@orange.com" 
> *Date: *Tuesday, October 11, 2016 at 4:14 AM
> *To: *Dhruv Dhody , "Zhangxian (Xian)" <
> zhang.x...@huawei.com>
> *Cc: *"pce@ietf.org" 
> *Subject: *Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE
> advising PCC about no path
>
>
>
> Hi,
>
>
>
> I would rather prefer to have a more generic statement for the PCC local
> policy :
>
>
>
> The ERO may be empty if the PCE cannot find a valid path for a delegated
> LSP. One typical situation resulting in this empty ERO carried in the PCUpd
> message is that a PCE can no longer find a strict SRLG-disjoint path for a
> delegated LSP after a link failure.  The PCC SHOULD implement a local
> policy to decide the appropriate action to be taken: tear down LSP, revoke
> delegation and use a locally computed path, keep existing LSP state …
>
>
>
> Brgds,
>
>
>
>
>
> *From:* dhruvdh...@gmail.com [mailto:dhruvdh...@gmail.com] *On Behalf Of 
> *Dhruv
> Dhody
> *Sent:* Monday, October 10, 2016 06:45
> *To:* Zhangxian (Xian)
> *Cc:* LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui,
> Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; pce@ietf.org
> *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE
> advising PCC about no path
>
>
>
> Hi Xian,
>
>
>
> I would avoid saying set of *paths* for delegated LSP, instead I would
> modify your text slightly as -
>
>
>
> The ERO may be empty if the PCE cannot find a valid path for a delegated
> LSP. One typical situation resulting in this empty ERO carried in the PCUpd
> message is that a PCE can no longer find a strict SRLG-disjoint path for a
> delegated LSP after a link failure.  If the PCC's local policy allows it,
> it SHOULD signal the tear down of the LSP. Alternatively, PCC MAY revoke
> delegation and use a locally computed path instead.
>
>
>
> Regards,
>
> Dhruv
>
>
>
> On Mon, Oct 10, 2016 at 8:15 AM, Zhangxian (Xian) 
> wrote:
>
> Hi, Stephane,  Olivier, All,
>
>
>
>   I support the option 1 Dhruv proposed (see below), which has least
> impact on existing implementations.
>
>
>
> >(1) Allow Empty ERO to mean no path.
>
> >Let it be valid in all messages to mean that no intended path exists for
> this LSP.
>
> >As per -16,
>
> >- empty ERO is added in the end of synchronization marker (PCRpt).
>
> >- The ERO may be empty if the PCE does not have a path for a delegated
> LSP.
>
>
>
> >We can add text in section 6.2 to say something like –
>
>
>
> >The ERO may be empty if the PCE does not have an intended path for the
> delegated LSP.
>
> >If the local policy allows it, the PCC SHOULD signal the tear down of
> the LSP. At
>
> >this time, PCC MAY also revoke delegation and use a locally computed
> path instead.
>
>
>
> >To me this is more logical and in spirit with the rest of the document,
> also would require least amount of changes in existing implementations.
>
>
>
> If we have rough consensus, we should start to work on the changes  needed
> in draft-ietf-pce-stateful-pce-16 to clarify, I would propose to add the
> following sentences in somewhere in Section 6.2 (edited on top of what
> Dhruv has suggested above):
>
>
>
> The ERO may be empty if the PCE cannot find one or a set of valid paths
> for a delegated LSP.  One typical situation resulting in this empty ERO
> carried in the PCUpd message is that PCE can no longer find two strictly
> SRLG-disjoint paths for a delegation LSP after link failure.  If its local
> policy allows it, the PCC SHOULD signal the tear down of the LSP.
> Alternatively, PCC MAY revoke delegation and use a locally computed path
> instead.
>
>
>
> Does the text look good to address the ambiguity issue you raised?
>
>
>
> Regards,
>
> Xian
>
>
>
> *发件人**:* Pce [mailto:pce-boun...@ietf.org] *代表 *
> stephane.litkow...@orange.com
> *发送时间:* 2016年10月6日 

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

[Cyril Margaria]

please see inline



3) Association control : the PCC and any PCE can create associations:
>  this diverge from the existing mechanism from the statefull document.
> In my opinion this aspect makes the control and state maintenance more
> complicated. The use cases behind this multiple-controller model is not
> very clear.
>
> If the association is under the control a single entity (PCC or PCE), as
> in the stateful document, the association state then become part of the PCE
> state and the rules described in the stateful document  applies (it up to
> the PCE who as delegation to set the association.
>
> This would also allow to get rid of the R bit, as mentioned by adrian (to
> remove an association: simply not send it)
>

### I disagree, the ability to have either create an association and
allocate an identifier was a key requirement (you may recall that version
00 only allowed the PCE to create such associations, and we received a lot
of feedback asking to lift this limitation).

[MC] I mixed different things here, some of them were clarified during the
discussion:
  -a)  Multiple-controller : I meant multiple PCE at the same time, the
authors clarified that only one PCE can set the association, the one having
the delegation.
This is  implicit because only PCUpd and PCInitiate can change the
association, Additional text could make it more clear, that address the "This
diverge from the existing mechanism from the statefull document."
  b) I agree that the ability to have either create an association and
allocate an identifier is a key requirement, this should be kept.
Do you mean that the R bit is required to do that? I did not find
this in the document. I have the view as Lou on it.
  c) Cleanup-procedure : this is addressed by the comment "3) to change the
association source to be the same as 6780" from Lou: as the state is not
per association source/PCE and point a), then the Associations is another
PCE-create parameter, so the draft-ietf-pce-stateful-pce
 and
draft-ietf-pce-pce-initiated-lsp
 do apply
and are sufficient to do the cleanup.

BR,
Cyril

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

[Pce] Question on draft-ietf-pce-stateful-pce-11

[Cyril Margaria]

Dear authors, PCE'ers,

Following the  comment on the Error-Type 19, Error-value 4 comments
(PCNtf), I have the following additional comments/questions regarding
section 7.3.3 LSP Error Code TLV:
   - When should each error code be sent, documents usually describe the
specific conditions when an error is sent, here the condition is that the
update failed, but the description of the errors is not very specific.
  - The Value 2 seems redundant with Error-Type 19, Error-value 4, or is
this error meant for the PCE to slow down the Update rate?
 - Value 3 (Too many pending LSP update requests) : What should be the PCE
action in that case, should the PCE stop sending the messages, slow down,
Could a NOTIFICATION object with a PCC overload state report be used,
following RFC5440? In addition should this the number of update request be
considered in section 9?
 - Value 4 (Unacceptable parameters) : How are the not acceptable parameter
reported, should the PCE retry with another set of parameters?
 -Value 5 : What should the PCE do in that case? is it recommended that it
stop sending updates? Could you explain why a PCE is not allowed to set LSP
parameters on a LSP in admin state down?
 - Value 6 (LSP preempted): Which kind of preemption  (administrative,
signaling, other PCE??) Is there a recommended action from the PCE, Should
the PCE compute a new Path or is it expected that the delegation is removed?

Best regards,
Cyril
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Few comments/queries on draft-ietf-pce-pce-initiated-lsp-04

[Cyril Margaria]

Hi,

On 10 June 2015 at 03:32, Venugopal Reddy K venugopalred...@huawei.com
wrote:

  Hi, Everyone!



 Have few comments/queries on draft-ietf-pce-pce-initiated-lsp-04. Could
 you please clarify on below points:



   Section 6

   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

 1.   In case of Backup PCE, what is the trigger point to send
 PCInitiate message to take control of orphan PCE-initiated LSP? I am
 wondering how does a backup PCE come to know that some LSPs are orphaned?

I see two scenarios :
  1) Another PCEP Session is up , in that case it seems to imply that the
PCE(s) keep track of the LSPs it can manage and the liveliness of the other
PCEs.
   2) There is no other PCEP session, the PCC reconnects to another PCE, in
this case the PCE can try to take ownership of the Initiated, not delegated
LSPs

 While I believe 1) is an interesting architecture, I do not think the
protocol procedures should put such constraint to the PCE implementation,
so the second option you propose should be allowed.




 2.   Another option would be, if PCC takes charge and delegate the
 orphaned PCE initiated LSPs to backup PCE based on the local policy?



I think this should be allowed, the text could be :

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 PCC MAY delegate the LSP to another PCE. the LSP is an
orphan until the expiration of the State
Timeout timer.


Some coordination between PCEs is still needed, for the original PCE to
regain control over that LSP the current PCE must forfeit control over that
LSP.

In addition there is no Error to indicate to the PCE that he can't have the
delegation back, this should be added , for instance 24,4

LSP instantiation error, Requested delegation rejected, another PCE
has the delegation. (ideally allow the optional inclusion of the other
PCE SPEAKER-IDENTITY-ID for troubleshooting. it should be subject to
security policies)



  Response will be appreciated.



 Thanks a lot.



 Regards,

 Venu



 Regards,
 Cyril


 ___
 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 on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

[Cyril Margaria]

Hi,

I have the following comments on draft-ietf-pce-pce-initiated-lsp-02:
Some comments require non minor changes (security section). I think the
document should progress, but I am not sure its fully ready for LC.

Section 3.2. Operation overview

- A PCE may return a delegation to the PCC in order to facilitate
re-delegation of its LSPs to an alternate PCE.
  In this context (protocol operation), a MAY seems appropriate.

Section 4.1:
-  In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced in
the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the same
format.


Section 5

 - The section is a mix of object definition and procedures, the procedures
could be more clearly marked (having separate object format and procedure
section, or changing the section titles)

Section 5.1.

 - The error procedure refers to I-D.ietf-pce-stateful-pce for a message
defined in this document, I-D.ietf-pce-stateful-pce should not define error
procedure for unknown message.
   I believe you are refering to the error values
  OLD:
  If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr as described in [I-D.ietf-pce-stateful-pce].

  NEW:
  If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr with error-type 6 (Mandatory Object missing) and error-value=10 (SRP
Object missing), respectively error-value=8 (LSP Object missing). Those
errors are defined defined in [I-D.ietf-pce-stateful-pce].

 - Section 3.2 has a more strict definition of the message content, that
matches the RBNF, namely including the ERO and ENDPOINTS objects,
   the text of section 3.2 sould be moved to this section (the overview
being more detailed than the definition), but its also repeated in section
5.3., maybe better to reference section 5.3 or have section 5.3 be a
procedures subsection

Section 5.2.

 - The type object is defined in [I-D.ietf-pce-stateful-pce].
  This sentence could be removed


Section 5.3

- OLD: The LSP is set up using RSVP-TE, extensions for other setup methods
are outside the scope of this draft.
  NEW: The LSP is assumed to be set up using RSVP-TE, extensions for other
setup methods are outside the scope of this draft.

- OLD: The END-POINTS Object is mandatory for an instantiation request of
an RSVP-signaled LSP.
  NEW: The END-POINTS Object is mandatory for an instantiation request.

 Regardless of RSVP or other protocol, the END-POINTS is required on a lot
of PCEP messages, so if new signaling protocols does not require the
END-POINTS, its better to leave the new definition that will affect other
PCEP messages to that document.

 - Error code 6 (Object missing) for a missing TLV seems confusing, its
more a malformed object content (as the TLV is part of the object), the TLV
missing error should be reparented to error-type=10 (Reception of an
invalid object)
 - If there is conflict with
   the LSP name, the PCC MUST send a PCErr message with Error-type=23
   (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use).
   The only exception to this rule is for LSPs for which the State
   timeout timer is running (see Section 6).
 I am unsure the exception is a good mechanism, this is detailed further in
the comment for section 6.


 - LSPs that were instantiated as a result of a PCInitiate message MUST
have the C flag set in the LSP object.
  C flag is not yet defined, please add reference to the section or has
Object extensions then procedures

 - If the PCC determines that the LSP parameters proposed in the
PCInitiate message are unacceptable, it MUST trigger a PCErr with
   error-type=TBD (PCE instantiation error) and error-value=1 (Unacceptable
instantiation parameters).

  This procedure is cleaner and offers more possibility for the PCE to know
which parameter was wrong, base draft should use the same

 - A PCC MUST relay to the PCE errors it encounters in the...
  This imply that the PCC SHOULD wait for the LSP to be signaled before
reporting the LSP State,  I would suggest the following text:

 The PCC SHOULD respond to the PCInitiate message when the LSP has been
signaled. On succesful completion ... (Last paragraph).
  On unsucessfull completion a PCC MUST relay ...

 - on PCInitiate , the Symbolic Path Name TLV is mandatory, the LSP
Identifiers TLVs may be present unless specified (I do not see any
drawback/limitation, behavior is the same as mplsTunnelIndex)
   is this correct?
 - Are the LSP Error Code TLV and  RSVP Error Spec TLV accepted, rejected
or ignored?
 - Section 5.3.1 indicated a new optional TLV (SPEAKER-IDENTITY-ID), maybe
a TLV presence rules section could be usefull, its now distributed over
different sections and levels.


Section 5.3.1.

 - Is there any specific reason to have the flag defined as a subsection of
the instantiation procedure rather than a separate section as the R flag?
 - Nits : draft-ietf-pce-stateful-pce-10 define Flag, the document defines
Flags, name should be aligned

 - If the TLV appears for an LSP for 

Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

[Cyril Margaria]

Hi,

I have the following comments on
draft-ietf-pce-stateful-sync-optimizations-01.


Section 3 :
  The documents proposes different optimizations, spending a paragraph or
two to describe the different optimizations, then a list of extensions, and
finish with procedures would help.

Section 3.2
 - A bit INCLUDE-DB-VERSION (IDB) is defined, section 7 defines the S bit.

Section 3.2.2
 - OLD: The type of the TLV is [TBD] and it has a a variable length, which
 MUST be greater than 0 and padded to 4-octet alignment (, and
padding
 is not included in the Length field).
 
   NEW: The type of the TLV is [TBD] and it has a a variable length, which
 MUST be greater than 0. The Value is padded to 4-octet alignment.
The  padding
is not included in the Length field

   The value field is padded, not the lenght


Section 4.

-  Incremental is not allowed, because Paragraph 6 of section 3.2 indicates:
   Otherwise, the PCC MUST perform state synchronization to the stateful
PCE.
   Section 3.2 should take into consideration all the bits defined, moving
the procedures after all the object definition would allow for an easier
understanding.
- proposes- defines

Section 4.2.
  - Figure 7: I believe this is the D flag, not the T flag

Section 5.

The use case is different from section 6, but they use the same bit to
advertize that capability, so if T bit is set, the PCC MUST/SHOULD/MAY wait
the trigger from the PCE??


Section 6.2.
 - OLD: The PCC MUST respond with a PCRpt message and SHOULD include the
SRP-ID-number of  the PCUpd that triggered the resynchronization.
   NEW: The PCC MUST respond with a PCRpt message with the LSP state, SYNC
Flag set to 0 and MUST include the SRP-ID-number of  the PCUpd that
triggered the resynchronization.
SHOULD - MUST.
draft-ietf-pce-stateful-pce-10, section 5.6.2 indicates that the
PCRpt MUST include the SRP id in the subsequent PCErr or PCRpt. I see no
justification in the text to change the mechanism described in
draft-ietf-pce-stateful-pce-10.
The SYNC flag MUST be set to 0, otherwise it may be confused with a
full sync.

 - I believe all those updates are scoped only to the session that
triggered the delta/PCE triggered sync, adding it explicitly would be good,
as its a change in the PCRpt mechanism of the PCC.

- What happens if the PCE sends multiple resync requests while the a full
resync is in progress?


Section 7:

- This should under section 3.3. PCEP Extensions, and refer to the section
defining the bit behavior,
- D bit requires the S bit to be set, correct? A corresponding error is
missing
- The behavior of T bit is not clear, see comment of section 5.
- T bit and DS bit combination : it seems the T bit behavior does not
depend on the INCLUDE-DB-VERSION and Delta, so it can be set independently.
This should be specified.


Manageability section is missing.

Section 8.3.
Suggested values are off, 29 is the suggested value of the I bit of
draft-ietf-pce-pce-initiated-lsp-02.
I believed this should be:

TBD(suggested value 27)  DELTA-LSP-SYNC-CAPABILITY   This document
TBD(suggested value 28)  TRIGGERED-SYNC  This document
TBD(suggested value 30)  INCLUDE-DB-VERSION  This document


Section 9.

 The document introduces new messages that may introduce load on the PCC, a
malicious PCE may flood the PCC with resync requests, this should be
mentioned.




On 1 December 2014 at 12:18, julien.meu...@orange.com wrote:

 Dear all,

 As planned, this message ignites a 3-week WG Last Call on both
 draft-ietf-pce-pce-initiated-lsp-02 and 
 draft-ietf-pce-stateful-sync-optimizations-01.
 It will end on Monday December 22 at 11:59 PM, HST.

 Please send your comments to the PCE mailing list.

 Thanks,

 JP  Julien


 
 _

 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 mailing list
Pce@ietf.org

Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

[Cyril Margaria]

Hi,

While reviewing draft-ietf-pce-stateful-sync-optimizations, I catched the
following additional nit:

SPEAKER-IDENTITY-ID - SPEAKER-ENTITY-ID

- Missing a Manageability Considerations section, following RFC6123



On 22 December 2014 at 11:36, Cyril Margaria cyril.marga...@gmail.com
wrote:

 Hi,

 I have the following comments on draft-ietf-pce-pce-initiated-lsp-02:
 Some comments require non minor changes (security section). I think the
 document should progress, but I am not sure its fully ready for LC.

 Section 3.2. Operation overview

 - A PCE may return a delegation to the PCC in order to facilitate
 re-delegation of its LSPs to an alternate PCE.
   In this context (protocol operation), a MAY seems appropriate.

 Section 4.1:
 -  In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced
 in the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the
 same format.


 Section 5

  - The section is a mix of object definition and procedures, the
 procedures could be more clearly marked (having separate object format and
 procedure section, or changing the section titles)

 Section 5.1.

  - The error procedure refers to I-D.ietf-pce-stateful-pce for a message
 defined in this document, I-D.ietf-pce-stateful-pce should not define error
 procedure for unknown message.
I believe you are refering to the error values
   OLD:
   If either the SRP or the LSP object is missing, the PCC MUST send a
 PCErr as described in [I-D.ietf-pce-stateful-pce].

   NEW:
   If either the SRP or the LSP object is missing, the PCC MUST send a
 PCErr with error-type 6 (Mandatory Object missing) and error-value=10 (SRP
 Object missing), respectively error-value=8 (LSP Object missing). Those
 errors are defined defined in [I-D.ietf-pce-stateful-pce].

  - Section 3.2 has a more strict definition of the message content, that
 matches the RBNF, namely including the ERO and ENDPOINTS objects,
the text of section 3.2 sould be moved to this section (the overview
 being more detailed than the definition), but its also repeated in section
 5.3., maybe better to reference section 5.3 or have section 5.3 be a
 procedures subsection

 Section 5.2.

  - The type object is defined in [I-D.ietf-pce-stateful-pce].
   This sentence could be removed


 Section 5.3

 - OLD: The LSP is set up using RSVP-TE, extensions for other setup
 methods are outside the scope of this draft.
   NEW: The LSP is assumed to be set up using RSVP-TE, extensions for
 other setup methods are outside the scope of this draft.

 - OLD: The END-POINTS Object is mandatory for an instantiation request of
 an RSVP-signaled LSP.
   NEW: The END-POINTS Object is mandatory for an instantiation request.

  Regardless of RSVP or other protocol, the END-POINTS is required on a lot
 of PCEP messages, so if new signaling protocols does not require the
 END-POINTS, its better to leave the new definition that will affect other
 PCEP messages to that document.

  - Error code 6 (Object missing) for a missing TLV seems confusing, its
 more a malformed object content (as the TLV is part of the object), the TLV
 missing error should be reparented to error-type=10 (Reception of an
 invalid object)
  - If there is conflict with
the LSP name, the PCC MUST send a PCErr message with Error-type=23
(Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use).
The only exception to this rule is for LSPs for which the State
timeout timer is running (see Section 6).
  I am unsure the exception is a good mechanism, this is detailed further
 in the comment for section 6.


  - LSPs that were instantiated as a result of a PCInitiate message MUST
 have the C flag set in the LSP object.
   C flag is not yet defined, please add reference to the section or has
 Object extensions then procedures

  - If the PCC determines that the LSP parameters proposed in the
 PCInitiate message are unacceptable, it MUST trigger a PCErr with
error-type=TBD (PCE instantiation error) and error-value=1
 (Unacceptable instantiation parameters).

   This procedure is cleaner and offers more possibility for the PCE to
 know which parameter was wrong, base draft should use the same

  - A PCC MUST relay to the PCE errors it encounters in the...
   This imply that the PCC SHOULD wait for the LSP to be signaled before
 reporting the LSP State,  I would suggest the following text:

  The PCC SHOULD respond to the PCInitiate message when the LSP has been
 signaled. On succesful completion ... (Last paragraph).
   On unsucessfull completion a PCC MUST relay ...

  - on PCInitiate , the Symbolic Path Name TLV is mandatory, the LSP
 Identifiers TLVs may be present unless specified (I do not see any
 drawback/limitation, behavior is the same as mplsTunnelIndex)
is this correct?
  - Are the LSP Error Code TLV and  RSVP Error Spec TLV accepted, rejected
 or ignored?
  - Section 5.3.1 indicated a new optional TLV (SPEAKER-IDENTITY-ID), maybe
 a TLV presence rules section

Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09

[Cyril Margaria]

Hi,

For the error handling on PCUpd, and instantiation draft, I think it would
be usefull to align the error procedures and capabilities.
in draft-ietf-pce-stateful-pce-10 the error is returned via PCRpt,
for the same kind of error its returned using a PCErr in
draft-ietf-pce-pce-initiated-lsp-02 ( error-type 24 (LSP instantiation
error) , error-value =1 (Unacceptable instantiation parameter) )

It would mean moving the definition  from instantion to stateful and
changing the type of error for one specific error type, this is not a too
big change,

BR
Cyril




On 27 October 2014 03:57, Cyril Margaria cyril.marga...@gmail.com wrote:

 Hi Ina,

 Thanks, see inline for the open points.

 On 27 October 2014 01:57, Ina Minei inami...@google.com wrote:

 Thank you for the careful review, please see inline ###.

 [snip]
 I Have the following comment for draft-ietf-pce-stateful-pce-09:

 Section 2
 The document references the following timers:
- State Timeout Interval
- Redelegation Timeout Interval

 RFC5440 defines an Appendix B. PCEP Variables, having a dedicated section
 for those variables would be better, as they are integral part of the
 extensions.


 ### They are discussed in the main part of the draft, their use etc is
 introduced as early as page 4 of the doc. The suggested values for these
 timers are added in the operational section in the appendix, where they
 logically belong and I don't think we want to move them.


 I think it will be easier for YANG/MIB module designers to have a small
 appendix for those, with recommended values repeated there. The rest of the
 document does not need to  be changed in that regards.





 Section 5.4

 After the first paragraph, add:
 The State synchronization start with a LSP state report having the SYNC
 Flag in the LSP Object set to 1.

 Reason: This would allow for the PCC to fully resend its database after
 the Initialization phase, and clarify the PCE operation.


 ### This is covered in the current text and also clearly shown in figure
 1. .


 It is implicit in the text,, I think making it explicit would be better
 for implementations.




 Section 5.6.2
 OLD
 If the PCC decides that the LSP parameters proposed in the PCUpd message
 are unacceptable, it MUST report this error by including the
 LSP-ERROR-CODE TLV (Section 7.3.3
 
 https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3
 )
 with LSP error-value=³Unacceptable parameters in the LSP object in the
 PCRpt message to the PCE

 NEW
 If the PCC decides that the LSP parameters proposed in the PCUpd message
 are unacceptable, it MUST report this error by including the
 LSP-ERROR-CODE TLV (Section 7.3.3
 
 https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3
 )
 with LSP error-value=³Unacceptable parameters in the LSP object in the
 PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that
 were
 not accepted in the PCRpt message.


 Reason: If the PCC includes the objects (current PCC values) that caused
 the PCUpd to be rejected, it would help the PCE avoid resending them. A
 PCErr would allow to include the objects, a new error type would be
 needed
 but error handling from PCE side should be rather easy. Another
 possibility is having the LSP-ERROR-CODE containing a list of
 Object-Class, OT .

 ### While I agree in principle, I think if we go down this road we
 should also include the reason
 why the object was rejected to make this useful. Unless others feel
 strongly, I would not add this.


 I think having the mechanism would be aldready usefull with existing error
 messages.
 Having WG feedback in also welcomed.




 Section 7.3.
 Nits: Using Synchronize would be better aligned with other bits
 definition

 S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on
 transmission
 and MUST be ignored on receipt.



 R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on
 transmission
 and MUST be ignored on receipt
   (or it is allowed on PCUpd?)

 O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on
 transmission and MUST be ignored on receipt.


 ### This would preclude use of these bits in future documents, so  I
 prefer not to add this.


 Reserved bit are usually defined as follows  Unassigned bits are
 considered reserved. They MUST be set to zero on transmission and MUST be
 ignored on receipt.

 So restricting those values on PCUpd in this document does not preclude
 another document indicating how to use them when supporting that other
 document (It will be likely negotiated). Moreover this allows the new
 defining document to make sure that those bits have a specific value when
 using the stateful document.






 Section 7.3.3.
   The error value ŒLSP preempted¹ could seem a bit redundant with ŒRSVP
 signaling error¹ and the corresponding RSVP preempted error code, I
 believe the error code ŒLSP preempted¹ should be seen when a PCC-local
 administrative preemption is made, and the RSVP signaling error

Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09

[Cyril Margaria]

Hi Ina,

Thanks, see inline for the open points.

On 27 October 2014 01:57, Ina Minei inami...@google.com wrote:

 Thank you for the careful review, please see inline ###.

 [snip]
 I Have the following comment for draft-ietf-pce-stateful-pce-09:

 Section 2
 The document references the following timers:
- State Timeout Interval
- Redelegation Timeout Interval

 RFC5440 defines an Appendix B. PCEP Variables, having a dedicated section
 for those variables would be better, as they are integral part of the
 extensions.


 ### They are discussed in the main part of the draft, their use etc is
 introduced as early as page 4 of the doc. The suggested values for these
 timers are added in the operational section in the appendix, where they
 logically belong and I don't think we want to move them.


I think it will be easier for YANG/MIB module designers to have a small
appendix for those, with recommended values repeated there. The rest of the
document does not need to  be changed in that regards.





 Section 5.4

 After the first paragraph, add:
 The State synchronization start with a LSP state report having the SYNC
 Flag in the LSP Object set to 1.

 Reason: This would allow for the PCC to fully resend its database after
 the Initialization phase, and clarify the PCE operation.


 ### This is covered in the current text and also clearly shown in figure
 1. .


It is implicit in the text,, I think making it explicit would be better for
implementations.




 Section 5.6.2
 OLD
 If the PCC decides that the LSP parameters proposed in the PCUpd message
 are unacceptable, it MUST report this error by including the
 LSP-ERROR-CODE TLV (Section 7.3.3
 https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3
 )
 with LSP error-value=³Unacceptable parameters in the LSP object in the
 PCRpt message to the PCE

 NEW
 If the PCC decides that the LSP parameters proposed in the PCUpd message
 are unacceptable, it MUST report this error by including the
 LSP-ERROR-CODE TLV (Section 7.3.3
 https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3
 )
 with LSP error-value=³Unacceptable parameters in the LSP object in the
 PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that were
 not accepted in the PCRpt message.


 Reason: If the PCC includes the objects (current PCC values) that caused
 the PCUpd to be rejected, it would help the PCE avoid resending them. A
 PCErr would allow to include the objects, a new error type would be needed
 but error handling from PCE side should be rather easy. Another
 possibility is having the LSP-ERROR-CODE containing a list of
 Object-Class, OT .

 ### While I agree in principle, I think if we go down this road we should
 also include the reason
 why the object was rejected to make this useful. Unless others feel
 strongly, I would not add this.


I think having the mechanism would be aldready usefull with existing error
messages.
Having WG feedback in also welcomed.




 Section 7.3.
 Nits: Using Synchronize would be better aligned with other bits definition

 S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
 and MUST be ignored on receipt.



 R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
 and MUST be ignored on receipt
   (or it is allowed on PCUpd?)

 O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on
 transmission and MUST be ignored on receipt.


 ### This would preclude use of these bits in future documents, so  I
 prefer not to add this.


Reserved bit are usually defined as follows  Unassigned bits are
considered reserved. They MUST be set to zero on transmission and MUST be
ignored on receipt.

So restricting those values on PCUpd in this document does not preclude
another document indicating how to use them when supporting that other
document (It will be likely negotiated). Moreover this allows the new
defining document to make sure that those bits have a specific value when
using the stateful document.






 Section 7.3.3.
   The error value ŒLSP preempted¹ could seem a bit redundant with ŒRSVP
 signaling error¹ and the corresponding RSVP preempted error code, I
 believe the error code ŒLSP preempted¹ should be seen when a PCC-local
 administrative preemption is made, and the RSVP signaling error should be
 used otherwise (the error node can be of value for the PCE)

 ###  I think there is value to keep preemption separate from signaling
 error, and I prefer to leave them
 distinct.


My comment was not much on removing it, but have the text scope them
better, as they are mutually exclusive, implementation wise I would like to
know when to send the PCEP preempted, and the signaling preempted.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] NULL PCUpdate message

[Cyril Margaria]

Hi,

From the definition, an empty PCUpd must contain an ERO, I think the
question boils down to having an empty ERO or an ERO that mirrors the last
ERO received. This is the only required parameter.

I would propose the following text to clarify:

Section 5.5.3:
Add: Upon reception of a PCUpd with D=0 a PCC MUST ignore the LSP object A
bit and  the ERO object content.

With that the Empty (I would not introduce a NULL message) PCUpd contains
SRP, LSP with PLSP-ID, all flags to 0, and an empty ERO.

Br
Cyril


On 9 October 2014 14:33, Ramana Yarlagadda ryarl...@juniper.net wrote:

  Hi All,

 I have a questions on sending the PCUpdate message to delegate an LSP from
 PCE to PCC. Can somebody please help me here to understand the PCUpdate
 message
 For delegating an LSP back to PCC.

 Re-delegation section talks about empty message but the PCUpdate request
 message definition
 Says that all  LSP parameters muse be sent.


 1. PCE requires to send an EMPTY LSP Update message to delegate an
LSP  back to PCC.

 What is an acceptable empty LSP message?

 Please refer to section 5.5.5 of draft “PCEP extensions for stateful PCE”
 for procedure of returning
 Delegation


 1. Section 6.2 of draft “PCEP extensions for stateful PCE” defines
the PCUpd message.


 - Three mandatory objects must be included in each PCUpd message. The
error codes

 Are defined to notify the sender if any of the mandatory objects missing
 in the PCUpdate
 Message.

 - Also, The draft says (copied text from section 6.2)
-

 “An LSP Update Request MUST contain all LSP parameters that a PCE wishes to
be set for the LSP. A PCC MAY set missing parameters from locally
configured defaults.  If the LSP specified in the Update Request is
already up, it will be re-signaled.


 A clear definition of NULL message would help us here.

 -thanks in advance
 -ramana



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


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

Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09

[Cyril Margaria]

Dear PCErs,

The document has been updated to reflect your comments and has been posted.

In addition we included the comments on IANA allocation received post LC.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-10

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

Best Regards,
Cyril


On 21 July 2014 05:38, Julien Meuric julien.meu...@orange.com wrote:

 Hi all.

 This WG last call has ended. The authors are expected to address the
 received comments (thank you John for the feedback). Chairs' review will
 follow.

 Thanks,

 JP  Julien


 Jul. 04, 2014 - Julien Meuric:

  Dear WG,

 Now that you all have some time dedicated to I-Ds, please consider this
 as part of your review list.

 This message ignites the WG LC on draft-ietf-pce-gmpls-pcep-extensions-09.
 Comments should be sent to the PCE mailing list by Friday July 18, 11:59
 PM, HST.

 Regards,

 JP  Julien

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



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

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

Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09

[Cyril Margaria]

Hi,

(maybe duplicated, I did not see my first email on the list after 1 hour)

I support draft-ietf-pce-stateful-pce-app-02 LC.
I Have the following comment for draft-ietf-pce-stateful-pce-09:

Section 2
The document references the following timers:
   - State Timeout Interval
   - Redelegation Timeout Interval

RFC5440 defines an Appendix B. PCEP Variables, having a dedicated section
for those variables would be better, as they are integral part of the
extensions.


Section 5.4

After the first paragraph, add:
The State synchronization start with a LSP state report having the SYNC
Flag in the LSP Object set to 1.

Reason: This would allow for the PCC to fully resend its database after
the Initialization phase, and clarify the PCE operation.

Section 5.6.1
OLD
Once an LSP is up, the PCC sends an LSP State Report carried on a
   PCRpt message to the PCE, indicating that the LSP's status is 'Up'.
   If the LSP could not be set up, the PCC sends an LSP State Report
   indicating that the LSP is Down' and stating the cause of the
   Failure.

NEW
Once an LSP is up, the PCC sends an LSP State Report carried on a
   PCRpt message to the PCE, indicating that the LSP's status is 'Up' or
'Active'.
   If the LSP could not be set up, the PCC sends an LSP State Report
   indicating that the LSP is Down' and stating the cause of the
failure.


OLD
In such cases, the PCC may choose to only send the PCRpt
   indicating the latest status ('Up' or 'Down¹).

NEW
In such cases, the PCC may choose to only send the PCRpt
   indicating the latest status (ŒActive¹, 'Up' or 'Down').


Reason : Active is also a possible state.


Section 5.6.2
OLD
If the PCC decides that the LSP parameters proposed in the PCUpd message
are unacceptable, it MUST report this error by including the
LSP-ERROR-CODE TLV (Section 7.3.3
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3)
with LSP error-value=³Unacceptable parameters in the LSP object in the
PCRpt message to the PCE

NEW
If the PCC decides that the LSP parameters proposed in the PCUpd message
are unacceptable, it MUST report this error by including the
LSP-ERROR-CODE TLV (Section 7.3.3
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3)
with LSP error-value=³Unacceptable parameters in the LSP object in the
PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that were
not accepted in the PCRpt message.


Reason: If the PCC includes the objects (current PCC values) that caused
the PCUpd to be rejected, it would help the PCE avoid resending them. A
PCErr would allow to include the objects, a new error type would be needed
but error handling from PCE side should be rather easy. Another
possibility is having the LSP-ERROR-CODE containing a list of
Object-Class, OT .


OLD
   Once an LSP is up, the PCC sends an LSP State Report (PCRpt message)
   to the PCE, indicating that the LSP's status is 'Up'.  If the LSP
   could not be set up, the PCC sends an LSP State Report indicating
   that the LSP is 'Down' and stating the cause of the failure.

NEW
   Once an LSP is up or active, the PCC sends an LSP State Report (PCRpt
message)
   to the PCE, indicating that the LSP's status is 'Up¹ (resp. 'Active').
If the LSP
   could not be set up, the PCC sends an LSP State Report indicating
   that the LSP is 'Down' and stating the cause of the failure.




Section 6.1
OLD
The RRO SHOULD be included by the PCC when the path is up,

NEW
The RRO SHOULD be included by the PCC when the path is up or active,

Section 7
Replace MUST by SHOULD, this is restricting a lot future documents (not
allowing to enforce/ignore gracefully some objects)

Section 7.3.
Nits: Using Synchronize would be better aligned with other bits definition

S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
and MUST be ignored on receipt.

R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
and MUST be ignored on receipt
  (or it is allowed on PCUpd?)
O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on
transmission and MUST be ignored on receipt.

Section 7.3.3.
  The error value ŒLSP preempted¹ could seem a bit redundant with ŒRSVP
signaling error¹ and the corresponding RSVP preempted error code, I
believe the error code ŒLSP preempted¹ should be seen when a PCC-local
administrative preemption is made, and the RSVP signaling error should be
used otherwise (the error node can be of value for the PCE)



BR
Cyril


On 6 October 2014 09:57, Dhruv Dhody dhruv.i...@gmail.com wrote:

 Hi WG,

 Support both the documents, and are basically ready for publications.

 I re-read the documents again, here are some nits/comments which can
 be handled along the process.

 

 For draft-ietf-pce-stateful-pce-app: (listed as a contributor)

 - In sec 3. Overview of the Stateful PCE Protocol Extensions; the word
 tunnel is used in below paragraph, for consistency with rest of the
 document can it be changed to LSP.

Re: [Pce] I-D Action: draft-ietf-pce-rfc7150bis-00.txt

[Cyril Margaria]

Hi,

I think Dhruv addition is good.
Should be added to the document.


On 30 July 2014 06:46, Dhruv Dhody dhruv.dh...@huawei.com wrote:

 Hi Julien,

 
  Hi Dhruv.
 
  I would say that, if the intend was to allow the specified TLV in objects
  where optional TLVs do not exist, it would not be phrased like this. All
 the
  same, it makes no harm to add explicitly allowing optional TLVs in the
 I-D.

 Here is my suggested wording -

 Abstract -
 OLD:
This document defines a facility to carry vendor-specific information
in PCEP using a dedicated object and a new Type-Length-Variable that
can be carried in any existing PCEP object.
 NEW:
This document defines a facility to carry vendor-specific information
in PCEP using a dedicated object and a new Type-Length-Value (TLV) that
can be carried in a PCEP object that supports TLVs.

 Introduction -
 OLD:
This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV
that can be used to carry arbitrary information within any PCEP
object that supports TLVs.
 NEW:
This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV
that can be used to carry arbitrary information within any existing or
future defined PCEP object that supports TLVs.

 
  By the way, your quotes allows us to catch a weird expansion of TLV:
  V stands for Value, not Variable...

 Oh yes! Good catch! Updated above..

 Regards,
 Dhruv

 
  Thanks,
 
  Julien
 
 
  Jul. 30, 2014 - Dhruv Dhody:
   Hi Authors, WG,
  
   As we are in midst of a bis for 7150, I wanted to bring this to the
 notice
  of the WG.
   There was a offline discussion about the use of VENDOR-INFORMATION-TLV
 in
  the LSP object defined in stateful PCE draft.
  
   In Abstract it says..
  
   This document defines a facility to carry vendor-specific
 information
   in PCEP using a dedicated object and a new Type-Length-Variable
 that
   can be carried in any existing PCEP object.
 
  
   In Introduction it says..
  
   This document also defines a new PCEP TLV, the
 VENDOR-INFORMATION-TLV
   that can be used to carry arbitrary information within any PCEP
   object that supports TLVs. ^^^
  
   Surely the intention was to allow the use of VENDOR-INFORMATION-TLV in
  *any* PCEP object (existing or defined in future) that allow optional
 TLVs.
   We hope this can be clarified / made explicit in the bis to avoid any
  confusion.
  
   Regards,
   Dhruv
  
   -Original Message-
   From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
   internet-dra...@ietf.org
   Sent: 22 July 2014 19:12
  
   A New Internet-Draft is available from the on-line Internet-Drafts
   directories.
 This draft is a work item of the Path Computation Element Working
   Group of the IETF.
  
Title   : Conveying Vendor-Specific Constraints in
 the
  Path
   Computation Element communication Protocol
Authors : Fatai Zhang
  Adrian Farrel
  Filename: draft-ietf-pce-rfc7150bis-00.txt
  Pages   : 12
  Date: 2014-07-22
  
   Abstract:
   The Path Computation Element communication Protocol (PCEP) is
 used to
   convey path computation requests and responses both between Path
   Computation Clients (PCCs) and Path Computation Elements (PCEs)
 and
   between cooperating PCEs.  In PCEP, the path computation requests
   carry details of the constraints and objective functions that the
 PCC
   wishes the PCE to apply in its computation.
  
   This document defines a facility to carry vendor-specific
 information
   in PCEP using a dedicated object and a new Type-Length-Variable
 that
   can be carried in any existing PCEP object.
  
   This document obsoletes RFC 7150.  The only change from that
 document
   is the allocation of a different code point for the
   VENDOR-INFORMATION object.
  
  
   The IETF datatracker status page for this draft is:
   https://datatracker.ietf.org/doc/draft-ietf-pce-rfc7150bis/
  
   There's also a htmlized version available at:
   http://tools.ietf.org/html/draft-ietf-pce-rfc7150bis-00
  
  
   Please note that it may take a couple of minutes from the time of
   submission until the htmlized version and diff are available at
  tools.ietf.org.
  
   Internet-Drafts are also available by anonymous FTP at:
   ftp://ftp.ietf.org/internet-drafts/
  
   ___
   Pce mailing list
   Pce@ietf.org
   https://www.ietf.org/mailman/listinfo/pce
  
   ___
   Pce mailing list
   Pce@ietf.org
   https://www.ietf.org/mailman/listinfo/pce
  

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

___
Pce mailing list
Pce@ietf.org

Re: [Pce] Last IPR Check on draft-ietf-pce-gmpls-pcep-extensions

[Cyril Margaria]

Hi,

I am not aware of any IPR that applies to
draft-ietf-pce-gmpls-pcep-extensions.

Best Regards,
Cyril


On 22 July 2014 11:27, Julien Meuric julien.meu...@orange.com wrote:

 Dear authors of the aforementioned document,

 Has all IPR that applies to draft-ietf-pce-gmpls-pcep-extensions been
 disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and
 5378 for more details)

 A response from each of you is expected.

 Regards,

 JP  Julien


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

Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09

[Cyril Margaria]

H Jonathan,

Thanks a lot for your review,
please see inline.


On 18 July 2014 10:22, Jonathan Hardwick jonathan.hardw...@metaswitch.com
wrote:

 I've reviewed this document for the WG last call.
 I think this document is in good shape.  I only found nits - see below.
 Best regards
 Jon


 == Section 1.3 ==
 Change
   A new object type are introduced for the BANDWIDTH object
 to
   Two new object types are introduced for the BANDWIDTH object


 Agree


 == Section 2.2 ==
 Final paragraph second sentence - I think you should change this to
 Otherwise, the PCE MAY use... to make it clear that the second sentence
 is not intended to contradict the first sentence.


 Agree

 == Section 2.3 ==
 Page 9, directly under Traffic Spec field encoding table
 - there is a stray comma that should be deleted
 - change is MUST specify... to it MUST specify...
 - change As specified i [RFC5440] to As specified in [RFC5440]
 - change BANDWIDTH object of with object type 1 to BANDWIDTH object of
 object type 1


 Agree


 == Section 2.4 ==
 Page 11, directly under Traffic Spec field encoding table
 - there is a stray full stop (period) that should be deleted
 - change is MUST specify... to it MUST specify...


 Agree


 == Section 2.5.1 ==
 List of 5 items on page 12.  Should the LABEL-REQUEST TLV also be in this
 list?


 This is correct, the TLV will be added to the list


 == Section 2.6 ==
 Change
   IP address subobject MUST be a link subobject.
 to
   If an IP address subobject is used, then the IP address given MUST be
 associated with a link.

 Agree


 Change
   The procedure associated with this subobject is as follow
 to
   The procedure associated with this subobject is as follows.

 Agree


 Change
   MUST allocate one label of from within the set of label values
 to
   MUST allocate one label from within the set of label values

 Agree


 Change
If the PCE does not assign labels a response with a
NO-PATH and a NO-PATH-VECTOR-TLV with the bit .'No label resource in
range' set.
 to
If the PCE does not assign labels then it sends a response with a
NO-PATH object, containing a NO-PATH-VECTOR-TLV with the bit 'No label
 resource in
range' set.


 Agree

 == Section 2.7 ==
 Is your intention that the Label Subobject can also be used in the EXRS
 (RFC 5521 section 2.2?)  I think it is worth adding a sentence saying so.


This is correct


 For consistency with section 2.6 (and because I think the text in 2.6 is
 clearer) I think you should change this:
XRO Label subobjects MUST follow the numbered or unnumbered interface
subobjects to which they refer.  Each subobject represent one label,
several XRO Labels subobject MAY be present for each link.
 to this:
The Label subobject MUST follow a subobject identifying a link,
currently an IP address subobject (Type 1 or 2) or an interface id
(type 4) subobject.  If an IP address subobject is used, then the
IP address given MUST be associated with a link.  More than one
label suboject MAY follow each link subobject.


 Agree


 == Section 5.1 ==
 The formatting used in this section is not consistent.  Use consistent
 indentation  column width.
 For BANDWIDTH object I think you mean 5-15: Unassigned
 For ENDPOINTS the reference should be to 2.5, not 2.3


I agree,


 == Section 5.5 ==
 Value=q0 should be Value=10


 Agree



 -Original Message-
 From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
 Sent: 04 July 2014 17:05
 To: pce@ietf.org
 Subject: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09

 Dear WG,

 Now that you all have some time dedicated to I-Ds, please consider this
 as part of your review list.

 This message ignites the WG LC on
 draft-ietf-pce-gmpls-pcep-extensions-09. Comments should be sent to the
 PCE mailing list by Friday July 18, 11:59 PM, HST.

 Regards,

 JP  Julien

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

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

Re: [Pce] WG Last Call for draft-ietf-pce-gmpls-pcep-extensions-09

[Cyril Margaria]

Hi,

Thanks a lot for your comments, please see inline


On 23 July 2014 05:17, Zhangxian (Xian) zhang.x...@huawei.com wrote:

 I have also reviewed this draft (A bit late though) and find no major
 issues with it.

 On top of Jon's suggestions, pls find mine below. If these cannot be
 captured together with WG LC, please consider them during the next process.

 Regards,
 Xian

 == Section 1.2 ==
 s/Switching Encoding/LSP encoding type


Agree

 s/RSVP/RSVP-TE (in multiple places), also suggest to expand it during
 first use

 Agree


 Old:
 We describe in this document a set of PCEP protocol extensions, including
 new objects, TLVs, encodings, error codes and procedures, in order to
 fulfill the aforementioned requirements.
 NEW:
 We describe in this document a set of PCEP protocol extensions, including
 new object types, TLVs, error codes and procedures, in order to fulfill the
 aforementioned requirements.


Agree



 == Section 1.3 ==
 s/ENDPOINTS/END-POINTS

 Agree

 In the list following “The covered PCEP extensions are:”,  is there a
 reason why the GMPLS capability TLV added to OPEN msg is not included?


There is no technical reason, this will be added.


 OLD:
 A new object type is introduced for the LOAD-BALANCING object (Generalized
 bandwidth),
 NEW:
 A new object type is introduced for the LOAD-BALANCING object (Generalized
 LOAD-BALANCING).


 Agree


 == Section 2.1.1 ==
 OLD:
 Those documents define bit 0 of the PCED TLV for Path computation with
 GMPLS link constraints.
 Comment: Since it has been defined already and not clear (as least to me)
 in current texts, I would suggest to reword as following:
 NEW:
 Those documents has defined bit 0 in PCE-CAP-FLAGS Sub-TLV of PCED TLV as
 “Path computation with GMPLS link constraints”.

 Agree, have defined maybe?


 == Section 2.1.2 ==
 Lots of places with “Section Section XX”, I suggest to do a global replace
 of “Section Section” with “Section”.

 Agree, for sure


 The description is GMPLS capable. Not consistent with IANA section,
 suggest to the latter to this, replacing “GMPLS Capability”.

 Agree


 == Section 2.3. ==
 The title is a bit strange, suggest to change it to “BANDWIDTH object
 extensions”, similar to other PCEP extensions Section titles.

 Agree


 OLD:
 This correspond to requirement 3,4,5 and 11 of [RFC7025].
 Comment: RFC7025 Section 3.1 and 3.2 both have requirement 3, it is better
 to be more specific.
 NEW:
 This corresponds to requirements 3, 4, 5 and 11 of [RFC7025] Section 3.1.


Agree


 OLD:
 This document defines two OT for the BANDWIDTH object.t:
 NEW:
 This document defines two Object Types for the BANDWIDTH object:


 Agree


 The Bw Type field determines which type of bandwidth is represented by the
 object.
 Comment: The field name in the encoding and in the text is not consistent:
 Bw Spec Type vs. Bw Type. Please update (in two places)

 Agree, I will change for Bw Spec Type


 == Section 2.4. ==
 The title is a bit strange, suggest to change it to “LOAD-BALANCING object
 extensions”, similar to other PCEP extensions Section titles.

 Agree


 OLD:
 …each path using at minimum 2VC4 container,…
 NEW:
 …each path using at minimum 2 x VC4 container,…

 Agree


 == Section 2.5.1 ==
 OLD:
 For endpoint type Point-to-Multipoint several endpoint objects may be
 present in the message and represent a leave…
 NEW:
 For endpoint type Point-to-Multipoint, several endpoint objects may be
 present in the message and each represents a leave,…

 Agree

 s/ one of those TLV/one of those TLVs

 Agree


 == Section 2.5.2.4 ==
 Are the following two sentences meant the same? If so, suggest to delete
 the 2nd  one.
 1: Its format is the same as described in [RFC3471] Section 3.1
 Generalized label request.
 2: The fields are encoded as in the RSVP-TE.

 Agree, I will replace by  Its format and encoding is the same as
described


 OLD:
 The Encoding Type indicates the encoding type, e.g., SONET/SDH/GigE etc.,
 that will be used with the data associated.
 Comment: not clearly explained. Maybe change to the following?
 NEW:
 The Encoding type indicates the encoding type, e.g., SONET/SDH/GigE etc.,
 of the LSP with which the data is associated.

 Agree


 == Section 2.7 ==
 s/in order to fulfill requirement 13 of [RFC7025] section 4.1,/ in order
 to fulfill requirement 13 of [RFC7025] section 3.1,

 Agree


 == Section 2.8 ==
 OLD:
 This object is introduced to fulfill requirement 7 of [RFC7025] section
  4.1 and requirement 3 of [RFC7025] section 4.2.  This object contains the
 the value of the PROTECTION object defined by [RFC4872]  and may be used as
 a policy input.
 NEW:
 This object is introduced to fulfill requirement 7 of [RFC7025] Section
 3.1 and requirement 3 of [RFC7025] Section 3.2.  This object contains the
 value of the PROTECTION object defined by [RFC4872] and may be used as a
 policy input.


Agree

 Comment: contains the value or contains the information?

 I think contains the information would be more 

Re: [Pce] FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt

[Cyril Margaria]

Hi Young,

This update reflects all my comments, I am OK with this version.

Best Regards,
Cyril.



On 28 April 2014 12:31, Leeyoung leeyo...@huawei.com wrote:

 Hi Julien,

 This update reflects all the comments received from Cyril and Ramon as
 part of the WG LC.

 Cyril, please let the WG know if this update satisfies your comment.

 Best Regards,
 Young

 -Original Message-
 From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of
 internet-dra...@ietf.org
 Sent: Monday, April 28, 2014 11:29 AM
 To: i-d-annou...@ietf.org
 Cc: pce@ietf.org
 Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-12.txt


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

 Title   : PCEP Requirements for WSON Routing and
 Wavelength Assignment
 Authors : Young Lee
   Greg Bernstein
   Jonas Martensson
   Tomonori Takeda
   Takehiro Tsuritani
   Oscar Gonzalez de Dios
 Filename: draft-ietf-pce-wson-routing-wavelength-12.txt
 Pages   : 14
 Date: 2014-04-28

 Abstract:
This memo provides application-specific requirements for the Path
Computation Element communication Protocol (PCEP) for the support of
Wavelength Switched Optical Networks (WSON). Lightpath provisioning
in WSONs requires a routing and wavelength assignment (RWA) process.
From a path computation perspective, wavelength assignment is the
process of determining which wavelength can be used on each hop of a
path and forms an additional routing constraint to optical light
path computation. Requirements for Optical impairments will be
addressed in a separate document.





 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-pce-wson-routing-wavelength-12

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-routing-wavelength-12


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

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

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

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

Re: [Pce] 答复: Adoption of draft-ali-pce-remote-initiated-gmpls-lsp-03.txt as PCE WG Document ?

[Cyril Margaria]

Support


On 4 March 2014 23:30, Qin Wu bill...@huawei.com wrote:

 Support.

 -邮件原件-
 发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Zafar Ali (zali)
 发送时间: 2014年3月4日 22:22
 收件人: JP Vasseur (jvasseur); pce@ietf.org
 主题: Re: [Pce] Adoption of draft-ali-pce-remote-initiated-gmpls-lsp-03.txt
 as PCE WG Document ?

 Hi-

 Support (as a co-author).

 Thanks

 Regards Š Zafar


 -Original Message-
 From: JP Vasseur   (jvasseur) jvass...@cisco.com
 Date: Tuesday, March 4, 2014 5:51 AM
 To: pce@ietf.org pce@ietf.org
 Subject: [Pce] Adoption of draft-ali-pce-remote-initiated-gmpls-lsp-03.txt
 as PCE WG Document ?

 Dear WG,
 
 As discussed during the PCE WG meeting today where we had some support
 for adopting draft-ali-pce-remote-initiated-gmpls-lsp-03.txt
 as a PCE WG.
 
 Would you be in favor/opposed (and why if you want to justify) of
 adopting draft-ali-pce-remote-initiated-gmpls-lsp-03.txt as a WG
 document ?
 
 Thanks.
 
 JP and 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 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] comments draft-ietf-pce-stateful-pce-08.txt

[Cyril Margaria]

Hi,


I agree with Xian the  applicability consider those use case and the
passive statefull in general.
In order to support the passive stateful use case it seems to be a bit
overkill to create a separate document to revert an optional object from 2
revision ago.

Best Regards.





On 3 March 2014 03:21, Zhangxian (Xian) zhang.x...@huawei.com wrote:

  Hi, Ina, and all,



As for b), I do not think it is entirely true.  In the restoration
 section(Section 5.4.2), It mentions the existing method provided by RFC5521
 and the advantage of a stateful PCE. So, this is a good example of using
 PLSP-ID instead of providing detailed LSP information (such as ERO etc.),
 even though It may not be as obvious as you want it.



 Another related example, in the last paragraph of Section 5.4 (Recovery),
 it states as the following:



 “ A passive stateful PCE maintains the updated SRLG information of the

established LSPs in a centralized manner.  Therefore, the PCC can

specify as constraints to the path computation the SRLG disjointness

of a set of already established LSPs by only providing the LSP

identifiers.”



 Although Dhruv, Cyril and Ramon mentioned different usage, but the
 extensions required are the same, putting LSP object into the PCReq/PCRep
 (Note: This will be OPTIONAL). So it actually proves, from different
 angles, the need of such an extensions. Cyril and Dhruv’s use cases are
 recovery/optimization related, they should fall into the scope of
 applicability draft since we already have these use cases already. I will
 talk with them to see how what they have in mind can be reflected in the
 applicability draft to explicitly support such a requirement. As for
 Ramon’s suggestion, it seems to me, more operational driven. So, I am not
 sure it should be included in the applicability draft or it should be
 mentioned in the base draft (as a reason to support such extensions)?
  Thoughts?



 As for Ina’s suggestion of making a separate document, I am not sure it
 should be done this way. Recovery/re-optimization is fundamental, thus
 should be part of the base extensions. If you agree/disagree, can share
 your thoughts please?



 Regards,

 Xian



 *From:* Ina Minei [mailto:inami...@google.com]
 *Sent:* 2014年3月1日 9:05
 *To:* Zhangxian (Xian)
 *Cc:* Cyril Margaria; Ramon Casellas; pce@ietf.org

 *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt



 All,



 To Xian's question, as we explained in the wg meeting, the LSP object in
 PCReq and PCRep was removed because:

 a) there was no further mention anywhere in the document on the use in
 those messages, or of the LSP object in those messages, or of the values of
 its fields (as can be seen from this thread, different people used them
 differently).

 b) no use cases were specified in the applicability document for this use.



 I think specifying the use cases and the accompanying operation would make
 for a very good separate document.



 Ina







 On Thu, Feb 27, 2014 at 10:32 PM, Zhangxian (Xian) zhang.x...@huawei.com
 wrote:

 Hi, All,



  I also support adding this function. I remember previous version of
 this draft (v6) does support this (see:
 http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.4).
 It would be good to explain why it is removed in the current version if not
 before. Also, how the following scenarios mentioned by Cyril, Ramon  Dhruv
 could be addressed if v8 is used. That would help to see if this function
 is indeed useful.



 Regards,

 Xian



 *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
 *Sent:* 2014年2月27日 16:44
 *To:* Ramon Casellas
 *Cc:* pce@ietf.org


 *Subject:* Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt



 Hi

 I agree with Ramon and Druv.

 In addition to those use case, the LSP object in PCReq/PCRep is also
 applicable for non-delegated LSP in an active stateful PCE case.

 One example can be the rerouting after a failure, this may affect
 delegated and non delegated LSPs, the Stateful PCE would be benefit from
 knowing which non delegated LSP is to be rerouted.

 BR,

 Cyril.



 On 27 February 2014 07:40, Ramon Casellas ramon.casel...@cttc.es wrote:

 El 27/02/2014 3:43, Dhruv Dhody escribió:





  What is not available today is to send the LSP object in the PCReq,

 Ina since you bring this up, IMO LSP object in PCReq for passive stateful
 PCE can be useful in case of re-optimization, exclusion etc.

 Some extensions to PCEP are needed to do that, but the first step would be
 to identify an LSP in PCReq message.



 Dhruv, Ina, all

 TLDR +1. Just fwiw, in one of our use cases, a front-end stateful PCE
 may delegate a complex (e.g. optical)
 computation/re-optimization/defragmentation to a back-end PCE, and both
 the TED and LSPDB are shared between the pool of PCEs. In previous versions
 of the draft, we used the LSP object that was included within a PCEP
 request. There was the issue about the plspid, our

Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

[Cyril Margaria]

Hi

I agree with Ramon and Druv.
In addition to those use case, the LSP object in PCReq/PCRep is also
applicable for non-delegated LSP in an active stateful PCE case.
One example can be the rerouting after a failure, this may affect delegated
and non delegated LSPs, the Stateful PCE would be benefit from knowing
which non delegated LSP is to be rerouted.


BR,
Cyril.


On 27 February 2014 07:40, Ramon Casellas ramon.casel...@cttc.es wrote:

  El 27/02/2014 3:43, Dhruv Dhody escribió:



   What is not available today is to send the LSP object in the PCReq,
 Ina since you bring this up, IMO LSP object in PCReq for passive stateful
 PCE can be useful in case of re-optimization, exclusion etc.
  Some extensions to PCEP are needed to do that, but the first step would
 be to identify an LSP in PCReq message.


 Dhruv, Ina, all

 TLDR +1. Just fwiw, in one of our use cases, a front-end stateful PCE
 may delegate a complex (e.g. optical)
 computation/re-optimization/defragmentation to a back-end PCE, and both
 the TED and LSPDB are shared between the pool of PCEs. In previous versions
 of the draft, we used the LSP object that was included within a PCEP
 request. There was the issue about the plspid, our approach was based on
 using a dummy plspid and refer to the LSP entry in the database by its
 symbolic name (primary key).

 In short, we did find it useful to be able to refer to an LSP within the
 db when requesting computations between collaborating PCEs. Indeed, much
 like Dhruv's, for this specific use case, the backend is stateful but
 passive. The alternative is to provide the RRO, but the db contains other
 relevant information that cannot be conveyed in a rfc5440 re-optimization

 Thanks
 Ramon

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


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

Re: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10

[Cyril Margaria]

Hi PCErs,

I have a few comments on the document:


Section 1.1 : Strange indentation


indentation:

The indentation of the following section is not consistent:

Section 1.1
Section 2.1
Section 2.1.1
Section 3.1
Section 3.2
...



Section 2.1.1
=

Is there a requierement for RWA-capable PCE discovery?
IGP-based discovery is addressed in section 3.5, but OPEN extension could
also be covered.
A PCC expecting RWA-capable PCE will only be able to detect a non RWA
capable upon request.
It is likely that request are not very frequent in WSON networks, so a
misconfiguration may be discovered quite late.
OPEN extension would allow a faster detection.



Req 2) : I believe ii) is not only for D-RWA, but also covers RWA.
OLD:
 (i) Explicit Label Control (ELC) [RFC4003]

 (ii)Non-Explicit labels in the form of Label Sets (This will
allow Distributed WA at a node level where each node would
select the wavelength from the Label Sets)

NEW:
 (i)  Explicit Label Control (ELC) [RFC4003].

 (ii) Non-Explicit labels in the form of Label Sets. The PCC can select
the label based on local policy.

   Note that option ii) may also be used in R+WA or DWA.


Section 2.1.2
=

  Is it possible to mix in a bulk request, R and RWA requests?

Section 2.1.4
=


OLD
   For any PCReq Message that is associated with a request for
   wavelength assignment the requester (PCC) MUST be able to specify a
   restriction on the wavelengths to be used.
NEW
   For a RWA request, the request MUST be able to specify an option for
   a restriction on the wavelengths to be used.
   The requester MAY use this option to restrict the assigned wavelenght for
   Explict Label or Label Sets.

--
 This is more in line with the rest of the document. The req being on the
protocol, not involving the PCC is better.

OLD
   Note that the requestor (PCC) is NOT required to furnish any range
   restrictions. This restriction is to be interpreted by the PCE as a
   constraint on the tuning ability of the origination laser
   transmitter.

NEW
   Note that the requestor is NOT required to furnish any range
   restrictions. This restriction may for example come from the tuning
   ability of a laser transmitter, any optical element, or an policy based
restriction.

--
 The PCE should not interpret the restriction, just apply it.

Section 2.1.5
=

in The PCReq Message May include specific operator's policy, do you mean
MAY?

The section could be renamed Wavelength assignement policy constraints

The explicit label versus Label set could also fit in this section, or
section 2.1.1 req 2 should refer to this section.

OLD
  The PCReq Message SHOULD be able to request, when requesting a 1+1
  connection (e.g. link disjoint paths), that both paths use the same
  wavelength.
NEW
  A request for 2 or more path MUST be able to specify an option
constraining the path to have the same wavelength(s) assigned.


--
 Computing a 1+1 path is one use case, but this may apply for other
protection type. This can be achieved by removing the protection aspect.

Section 2.1.6
=

NEW
  o OIC list

--

draft-ietf-ccamp-rwa-info-21 defines the concept of OIC, PCEP should be
able to transport the same kind of info


Best regards,
Cyril



On 18 February 2014 17:28, Julien Meuric julien.meu...@orange.com wrote:

 Hi all.

 This last call has ended. We have not seen many reviews. The chairs' will
 come soon.

 JP  Julien


 Feb. 03, 2014 - Julien Meuric:

  Hi all.

 Since many of you are going to dedicate some time to IETF matters over
 the upcoming days, here comes some homework.

 This message ignites a 2-week WG last call on 
 draft-ietf-pce-wson-routing-wavelength-10.
 It will end on Monday, February 17, 11:59 PM (UTC-12).

 Thanks,

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