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] 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] 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] 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] 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] 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] 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] Poll for Adoption of draft-crabbe-pce-pce-initiated-lsp-03

[Cyril Margaria]

Support,

Thanks,
Cyril


On 13 November 2013 11:22, Ramon Casellas  wrote:

> Support,
>
> 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] Poll for Adoption of draft-zhang-pce-pcep-stateful-pce-gmpls-03

[Cyril Margaria]

Support,

Thanks,
Cyril


On 12 November 2013 15:17, Julien Meuric  wrote:

> Hi again.
>
> Following the support expressed in the room during our meeting in
> Vancouver, we would like to get the feedback of the mailing list: do you
> support draft-zhang-pce-pcep-stateful-pce-gmpls-03 to become a foundation
> for a PCE WG document?
>
> As usual, reasons for your preference are welcome (not to say mandatory in
> case of opposition).
>
> 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] Calling for PCE WG review, draft-ietf-pce-gmpls-pcep-extensions-09.txt

[Cyril Margaria]

Hi PCErs,

The Authors think that this document is ready for last call. We are calling
for review and comments.

This revision addressed all the comments raised since the document is
stable. Those can be summarized as follows:

 - RG flag semantic allowing easier checks and verifications.
 - Remove the need of extra object definition for GMPLS Bw encoding
 - Simplify object presence rules for asymmetric bandwidth
 - GMPLS extension can be negotiated on session opening, for early
detection.


Comments are welcomed on the list or to the authors:
draft-ietf-pce-gmpls-pcep-extensi...@tools.ietf.org

Best Regards,


-- Forwarded message --
From: 
Date: 14 February 2014 01:40
Subject: I-D Action: draft-ietf-pce-gmpls-pcep-extensions-09.txt
To: i-d-annou...@ietf.org
Cc: pce@ietf.org



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

Title   : PCEP extensions for GMPLS
Authors : Cyril Margaria
  Oscar Gonzalez de Dios
  Fatai Zhang
Filename: draft-ietf-pce-gmpls-pcep-extensions-09.txt
Pages   : 35
Date: 2014-02-13

Abstract:
   This memo provides extensions for the Path Computation Element
   communication Protocol (PCEP) for the support of GMPLS control plane.


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

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


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

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

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
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  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

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  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
>
> TL&DR +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] 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)  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) 
> 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  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
>

Re: [Pce] Adoption of draft-lopez-pce-pceps-02 as PCE WG Document ?

[Cyril Margaria]

support



On 5 March 2014 14:05, Leeyoung  wrote:

> Support.
>
> Young
>
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of JP Vasseur (jvasseur)
> Sent: Tuesday, March 04, 2014 3:48 AM
> To: pce@ietf.org
> Subject: [Pce] Adoption of draft-lopez-pce-pceps-02 as PCE WG Document ?
>
> Dear WG,
>
> As discussed during the PCE WG meeting today where we had good support for
> adopting draft-lopez-pce-pceps-02 as a WG document, as usual, we would like
> to confirm on the mailing list.
>
> Would you be in favor/opposed (and why if you want to justify) of adopting
> draft-lopez-pce-pceps-02 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

Re: [Pce] Adoption of draft-minei-pce-stateful-sync-optimizations as PCE WG Document?

[Cyril Margaria]

Support


On 5 March 2014 14:05, Leeyoung  wrote:

> Support.
>
> Young
>
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> Sent: Tuesday, March 04, 2014 12:12 PM
> To: pce@ietf.org
> Subject: [Pce] Adoption of draft-minei-pce-stateful-sync-optimizations as
> PCE WG Document?
>
> Dear WG,
>
> As discussed during the PCE WG meeting today, we had some support for
> adopting draft-minei-pce-stateful-sync-optimizations-01 as a PCE WG item.
>
> Would you be in favor/opposed (and why if you want to justify) of adopting
> it 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

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  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)" 
> Date: Tuesday, March 4, 2014 5:51 AM
> To: "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] 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  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] 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  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 
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)  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 i

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  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/pc

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
)
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
)
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  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.
>
>[I-D.ietf-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  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] 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  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 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  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
>> > >)
>> 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
>> > >)
>> 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/li

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  wrote:

> Hi Ina,
>
> Thanks, see inline for the open points.
>
> On 27 October 2014 01:57, Ina Minei  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
>>&g

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 

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 D&S 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,  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 mailin

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

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 
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] FW: New Version Notification for draft-minei-pce-association-group-01.txt

[Cyril Margaria]

Hi,

I did read the document, having PCE-initiated association is a good thing
in my opinion.

I think the following points should be added to the document:
1) capability negotiation
2) Considerations on how each peer should deal with the extra state, and
associated error codes to say "too many assiocations"

For the capability negotiation, I would like to contribute the following
text:

 "
4. Support of LSP association

   A PCEP speaker should be able to discover the other peer LSP
   association capabilities during the Open message exchange.
   This capability is also useful to avoid misconfigurations.
   The result of the negotiation does include which association types
   are supported by the other peer.


4.1.  OPEN Object extension ASSOCIATION-CAPABILITY TLV


   This document defines a new optional ASSOCIATION-CAPABILITY TLV for
   use in the OPEN object to negotiate the LSP association capability.
   The inclusion of this TLV in the OPEN message indicates that the
   PCC/PCE support the PCEP extensions defined in the document.  A PCE
   that is able to support the LSP Associaiton extensions defined in
   this document SHOULD include the ASSOCIATION-CAPABILITY TLV on the
   OPEN message. If either peer does not include the
   ASSOCIATION-CAPABILITY TLV  in the OPEN message, the PCCand the PCE
   MUST NOT use any of this document objects and procedure.

   The ASSOCIATION-CAPABILITY TLV carries the list supported
   association types. The association types supported by the session
   is the intersection of both peer list. the peer MUST NOT make use
   of any association type not in this list.

   IANA has allocated value TBA-1 from the "PCEP TLV Type Indicators" sub-
   registry, as documented in Section xx ("New PCEP TLVs").  The
   description is "ASSOCIATION-CAPABILITY".  Its format is shown in the
   following figure.

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=TBA-1  |Length (variable)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Type-capabilities |   ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Each supported association type is described by a 16-bit entry
consisting of the following fields:

Type (4 bits) : Supported association type
Type-capabilities (12 bits): Type-specific capabilities. This
field is defined by the document defining an association type.
"


Best regards,
Cyril

On 1 July 2015 at 21:03, Zhangxian (Xian)  wrote:

> Hi, PCErs,
>
> Last time when this draft was presented, we received lots of
> interests/comments. So this version addresses them and the major changes
> are briefly summarized as below:
>
> 1) object encoding updated (similar to RSVP-TE ASSOCIATION, but NOT the
> same);
>
> 2) added RBNF of this newly defined object in PCEP messages;
>
> 3) refined the text around these two updates, including allowing both PCE
> and PCC to create association etc.;
>
>Your comments are welcome!
>
> Regards,
> Xian (on behalf of all authors)
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: 2015年7月2日 8:55
> To: Edward Crabbe; Siva Sivabalan; Siva Sivabalan; Yosuke Tanaka;
> Hariharan Ananthakrishnan; Zhangxian (Xian); Ina Minei; Zhangxian (Xian);
> Edward Crabbe; Hariharan Ananthakrishnan; Ina Minei; Yosuke Tanaka
> Subject: New Version Notification for
> draft-minei-pce-association-group-01.txt
>
>
> A new version of I-D, draft-minei-pce-association-group-01.txt
> has been successfully submitted by Xian Zhang and posted to the
> IETF repository.
>
> Name:   draft-minei-pce-association-group
> Revision:   01
> Title:  PCEP Extensions for Establishing Relationships Between
> Sets of LSPs
> Document date:  2015-07-02
> Group:  Individual Submission
> Pages:  13
> URL:
> https://www.ietf.org/internet-drafts/draft-minei-pce-association-group-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-minei-pce-association-group/
> Htmlized:
> https://tools.ietf.org/html/draft-minei-pce-association-group-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-minei-pce-association-group-01
>
> Abstract:
>This document introduces a generic mechanism to create a grouping of
>LSPs in the context of a PCE.  This grouping can then be used to
>define associations between sets of LSPs or between a set of LSPs and
>a set of attributes (such as configuration parameters or behaviors),
>and is equally applicable to the active and passive modes of a
>stateful PCE as well as a stateless PCE.
>
>
>
>
>
> 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.
>
> The IETF S

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

[Cyril Margaria]

I have reviewed the id.

I think the document describes well the TLS  procedure.

I have the following comments/questions on the nonTLS support: what should
a PCE peer  do when the error code "pcep startTLS failure" and error value
3 or 4.

For error value 3 i believe closing the connection shoud be done
For error code 4 (ok without TLS) should the peer:

A)Continue without TLS at all

B) close and reconnect without using tls

A) would require more descrption of that case. B) would require the peer to
retry without tls or require a reconfiguration. The reconnect introduces
more states (how long to keep retrying withiut tls,... etc)

I think those points should be specified.

Best regards
Cyril
On Oct 8, 2015 18:57, "JP Vasseur (jvasseur)"  wrote:

> Dear WG,
>
> This starts a 2-week WG Last Call on draft-ietf-pce-pceps-04, ending on
> Oct 23 at noon ET. Please send your comments to the authors and copy the
> list.
>
> Thanks.
>
> JP, Julien and Jon.
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Cyril Margaria]

Hi,

My comments on the document are:


1)  The format goes in the good,direction, but is not yet fully aligned
with rfc6780, is this planned for a future revision?
2)  My concern is the following statements:

   "For both
   cases, the association is uniquely identified by the combination of
   an association identifier and the address of the PCE peer that
   created the association."

   "Association Source: 4 or 16 bytes - An IPv4 or IPv6 address, which is
   associated to the PCE peer that originated the association."

Those statement are not aligned with the RSVP association is managed.
The reason stated is that the association state is tied to that PCE.

Is this related to the fact that about any PCC/PCE can create
association on a LSP?

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)

Which use cases will not be permitted by that mode of operation?
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

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

[Cyril Margaria]

Support,

On 3 November 2015 at 19:36, Julien Meuric  wrote:

> Dear all,
>
> Following our discussion during the WG meeting yesterday, do you support
> the adoption of draft-minei-pce-association-group-03 as a starting point
> for a new PCE WG item? If not, please motivate your answer.
>
> In any case, comments are welcome.
>
> Regards,
>
> Jon, JP & Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] 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日 15:19
> *收件人:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC
> Julien IMT/OLN; pce@ietf.org
> *主题:* Re: [Pce] Urgent issue

[Pce] Comments on draft-ietf-pce-segment-routing-08

[Cyril Margaria]

Dear PCE'ers

I reviewed the document and I have the following comments/questions:

1)   The document implies that the PCC has to /MUST do IP address to
SID conversion, I  think that it would allow a more simpler PCC if that
capability is optional  and negotiated with additional error codes to
indicate that the NAI SR-EROs are not supported.

2)   One aspect of the SR-ERO processing is that,  when building the
label stack, the PCC should have enough information to decide on the
outgoing link (this can be provided by the PCE). It will be good if the
document state could spell out this part of the procedure and indicates any
specific SR-ERO procedure. For instance one solution could be  that the PCE
may use IP address or Adjacency SID to indicate the outgoing link.

3)   Taking the outgoing link selection into account, the Maximum Stack
Depth (MSD) calculation may be not trivial: for instance if the first hop
is a local Adjacency-SID, then the label will not be stacked, but it will
if the first hop is a Prefix SID it may be counted (non-adjacent node or
adjacent node without PHP) but it may not be counted (adjacent node, with
PHP). I think the draft should clarify it.

Thanks,

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

Re: [Pce] Comments on draft-ietf-pce-segment-routing-08

[Cyril Margaria]

Hi Stephane,

please see inline

On 14 November 2016 at 13:05,  wrote:

>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Cyril Margaria
> *Sent:* Monday, November 14, 2016 23:40
> Dear PCE'ers
>
> I reviewed the document and I have the following comments/questions:
>
> 1)  The document implies that the PCC has to /MUST do IP
> address to SID conversion, I  think that it would allow a more simpler PCC
> if that capability is optional  and negotiated with additional error
> codes to indicate that the NAI SR-EROs are not supported.
>
> [SLI] Usage of NAI in the SR-ERO is already optional today but driven by
> PCE. Do you mean that the PCC should drive the PCE computation result
> behavior ?
>

I think the PCC should be able to indicate if it supports NAI->SID
translation.
I see the following point missing :
  - There is no capability negotiation or specific error code to indicate
that the PCC does not support S flag set to 0.
  - if NAI->SID translation is supported, What is the procedure/error code
if a PCC cannot  resolve a NAI to a SID?

 From PCE perspective this is a change in the format of the ERO, this does
not influence the path computation.


A new object may be created for this purpose as a new path constraint. But
> you also may fall into situations where the PCE does not support this new
> constraint requested by PCC. Then, it would be good to impose one method to
> be supported and others to be optional, this will ensure a real
> interoperability between all implementations.
>
I agree, the draft should mandate one method for SR support, but the other
should be negotiated..


> I would also prefer to limit the options… (does mixing SID and NAI make
> sense ? I do not see the use case behind)
>

The ERO should (points below excluded) be consistent, mixing SID-Only and
NAI-Only does not make much sense. Having both NAI and SID does make sense
for troubleshooting though.


> 2)  One aspect of the SR-ERO processing is that,  when
> building the label stack, the PCC should have enough information to decide
> on the outgoing link (this can be provided by the PCE). It will be good if
> the document state could spell out this part of the procedure and indicates
> any specific SR-ERO procedure. For instance one solution could be  that the
> PCE may use IP address or Adjacency SID to indicate the outgoing link.
>
> [SLI] Are you in the case of SID only used in ERO ? If NAI is used,
> outgoing if can be deduced from the first hop NAI, if NAI is not used, then
> it becomes not trivial and honestly I do not see how to deduce the
> interface (PCC cannot check its outgoing label database, as the same value
> may be used by multiple neighbors). NAI should be a MUST for the first hop ?
>
I think NAI is a must for the first hop.

3)  Taking the outgoing link selection into account, the
> Maximum Stack Depth (MSD) calculation may be not trivial: for instance if
> the first hop is a local Adjacency-SID, then the label will not be stacked,
> but it will if the first hop is a Prefix SID it may be counted
> (non-adjacent node or adjacent node without PHP) but it may not be counted
> (adjacent node, with PHP). I think the draft should clarify it.
>
> [SLI] I do not see why the first hop could be a local Adj-SID… if the ERO
> represents the stack to be used for the push operation, and if it starts
> with an Adj-SID, the Adj-SID should represent the first real forwarding
> operation. Going back to oif point, if NAI isn’t used, how can a PCC know
> that the first Adj-SID is a local SID or a neighbor’s SID ?
>
 I agree, if the PCC does not support NAI->SID, the first hop MUST include
a NAI for out interface selection.

If SID only is used and starts with an Adj-SID, the SR-ERO may be encoded
> using: NAI,Adj-SID,SID#1,SID#2,SID#3,…SID#n. The first hop defines only
> the oif.
>
In case the stack starts with a Node-SID, we may
> have:Node-SID+NAI,SID#1,SID#2,SID#3 …
>
Using this, we are always inline with MSD as we never send an ERO with more
> labels than supported.
>
>
>
This works if the first hop for outgoing link selection correspond to an
ADj-SID, I am not sure on the Node SID, it believe it depends if its a
neigbhor and PHP flag:

Following that for SID PCC only this would give the following stacks:
  - NAI,Adj-SID,SID#1,SID#2,SID#3: stack is SID#1,SID#2,SID#3 (stack size:
3)
  - Node-SID+NAI,SID#1,SID#2,SID#3:
   -  if the Node is adjacent with PHP:  SID#1,SID#2,SID#3 (stack
size: 3)
   -  if the Node is adjacent without PHP: Node-SID,SID#1,SID#2,SID#3
(stack size: 4)
   -  if the Node is  not adjacent :
Node-SID,SID#1,SID#2,SID#3 (stack size: 4)

For PCC supporting NAI translation:
  - NAI#0+(SID#0),NAI#1+(SID#1),NAI#2+(SID#2),NAI#3(+SID#3): stack is
SID#1,SID#2,S

Re: [Pce] Poll for adoption: draft-litkowski-pce-association-diversity

[Cyril Margaria]

Yes/Support

On 11 January 2017 at 10:13, Olivier Dugeon 
wrote:

> Yes/support
>
> Olivier
>
> Le 11/01/2017 à 14:44, Jonathan Hardwick a écrit :
>
> This is start of a two week poll on making 
> draft-litkowski-pce-association-diversity-01
> a PCE working group document.
>
> https://www.ietf.org/id/draft-litkowski-pce-association-diversity-01.txt
>
>
>
> 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 Wednesday January 25.
>
>
>
> Thanks,
>
> Jon, JP and Julien
>
>
>
>
> ___
> Pce mailing listPce@ietf.orghttps://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] Shepherd review of draft-ietf-pce-pceps

[Cyril Margaria]

Dear authors, PCE WG

I am the shepherd for this document, Please find below my shepherd's review
of the aforementioned I-D.


* General

The document does not need much work to to progress, they are mainly
clarifications.

* Detailed comments.

Section 3.2
--
"Thus the PCEP session is secured via TLS from the
   start before exchange of any other PCEP message including the Open
   message."

This sentence comes after the reference to discovery procedures while it
refers to when the startTLS message is to be used.
This could be rephrased.
--
"Securing via TLS of an existing PCEP session is not
   permitted, the session must be closed and re-established with TLS as
   per the procedure described in this document"

 Should the must be replaced by MUST?


--
"If the PCEP speaker supports PCEPS but cannot establish a TLS
   connection for some reason"

I believe that in that case both speakers must support PCEPS in order for
them to send the startTLS and start TLS negotiation. Its unclear when those
errors can be sent, shouldn't they be sent after the TLS negotiations have
taken place?
This comment is repeated in the next sections/comments.

Section 3.3.

--
"On receiving a StartTLS message from the PCEP
   peer (i.e.  when the PCEP speaker has sent and received StartTLS
   message) it is ready to start TLS negotiation and establishment and
   move to steps described in Section 3.4."

>From section 3.2  a peer MAY also send Error-Type set to [TBA2 by IANA]
(PCEP StartTLS failure) and Error-value 3 (not without TLS) or 4 (ok
without TLS).
At which point of the PCEP session are the PCErr sent? is it in step 3 of
 section 3.4?


--
"Once the TCP connection has been successfully established and the
   StartTLS message sent, the sender MUST start a timer called
   StartTLSWait timer, after the expiration of which, if no StartTLS
   message has been received, it sends a PCErr message and releases the
   TCP connection with Error-Type set to [TBA2 by IANA] and Error-value
   set to 5 (no StartTLS message received before the expiration of the
   StartTLSWait timer)."

the following text would be more clear in my opinion

"Once the TCP connection has been successfully established and the
   StartTLS message sent, the sender MUST start a timer called
   StartTLSWait timer, after the expiration of which, if no StartTLS
   message has been received, it MUST send a PCErr message and releases the
   TCP connection with Error-Type set to [TBA2 by IANA] and Error-value
   set to 5 (no StartTLS message received before the expiration of the
   StartTLSWait timer)."

Section 3.5



--
"PCEPS implementations SHOULD provide mechanisms for
   associating peer identities with different levels of access and/or
   authoritativeness, and they MUST provide a mechanism for establish a
   default level for properly identified peers. "

typo "for establish" -> "for establishing"

"PCEPS implementations SHOULD provide mechanisms for
   associating peer identities with different levels of access and/or
   authoritativeness, and they MUST provide a mechanism for establishing a
   default level for properly identified peers. "

--

" Implementations
   that want to support a wide variety of trust models should expose as
   many details of the presented certificate to the administrator as
   possible so that the trust model can be implemented by the
   administrator. "

should -> SHOULD or it could be rephrased if its not the intent.

--
"As a suggestion, at least the following parameters of
   the X.509 certificate should be exposed:"

it can be rephrased as
"At least the following parameters of
   the X.509 certificate SHOULD be exposed:"

or

"its RECOMMENDED that at least the following parameters of
   the X.509 certificate are exposed:"


Section 3.6
--

Section 3.2 defines error-values for TLS negotiation failures, should they
be used in that section? i.e the peer SHOULD send a PCErr and MUST
terminate the session?


Section 4.

--
I am not sure if the second and third paragraph are relevant for PCEPS
session establishement. Could you indicate what is the relation between
PCEPS and dns resolution?


Section 6.1

--

Following rfc5226, please  clarify the request for new allocation and
indicate which registry need to be updated, for instance:

 IANA is requested to allocate new message types within the "PCEP
 Messages" sub-registry of the PCEP Numbers registry, as follows:

 Value Meaning
 Reference
   TBA1  The Start TLS Message (StartTLS) This
document

Section 6.2

--
same as section 6.1, a possible text can be:

IANA is requested to allocate new Error Types and Error Values within
   the " PCEP-ERROR Object Error Types and Values" sub-registry of the
   PCEP Numbers registry, as follows:



Section 8.2

--
should the YANG modules also be updated?


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

Re: [Pce] Poll for adoption: draft-dhody-pce-pcep-exp-codepoints-03

[Cyril Margaria]

Yes/Support


On 10 April 2017 at 06:38, Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> All,
>
>
>
> This is the start of a two week poll on making 
> draft-dhody-pce-pcep-exp-codepoints-03
> a PCE working group document.
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/
>
>
>
> 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 Monday, April 24.
>
>
>
> Many thanks,
>
> Jon
>
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[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] 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 direction.
>
> 2.  We do not curren

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
>   Error-Type=3 ("Unknown Obje

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

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&url2=
> 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.
>
>
>
> *[[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:
>
>  - the "association information" is not define

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,

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&url2=
>> 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&url2=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&url2=
>> 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&url2=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 Ran

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

[Cyril Margaria]

Thanks a lot for the review,

please see responses inline, an updated revision will be posted shortly.


From: David Sinicrope 
Sent: Sunday, November 18, 2018 05:48
To: pce-cha...@ietf.org; draft-ietf-pce-gmpls-pcep-extensi...@ietf.org
Cc: BRUNGARD, DEBORAH A; Yemin (Amy); Jonathan Hardwick; pce@ietf.org
Subject: RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions


Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions

The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG. The early review can be performed at any time during the draft’s lifetime 
as a working group document. The purpose of the early review depends on the 
stage that the document has reached.

As this document is in working group last call, my focus for the review was to 
determine whether the document is ready to be published. Please consider my 
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-pce-gmpls-pcep-extensions-12.txt
Reviewer: David Sinicrope
Review Date: November 17, 2018
Intended Status: Standards Track

Summary:

  *   This document is basically ready for publication, but has nits and 
clarifications that should be considered prior to being submitted to the IESG.

Comments:

Although a bit terse on motivation the document is of good quality and detail 
providing the level of information needed for protocol specification and 
implementation.

The comments provided below are aimed at improving readability, comprehension 
and consumption of the document by those that would use it for architecture, 
solution design and implementation.



Abstract.  Please provide some detail scope and purpose beyond one line.  This 
is supposed to answer why / whether I should delve into the document.



[MC]
OLD:
This memo provides extensions to the Path Computation Element
communication Protocol (PCEP) for the support of GMPLS control plane.

NEW:
 The Path Computation Element (PCE) provides path computation
 functions for Multiprotocol Label Switching (MPLS) and Generalized
 MPLS (GMPLS) networks.  Additional requirements for GMPLS are
 identified in [RFC7025] .

This memo provides extensions to the Path Computation Element
communication Protocol (PCEP) for the support of the GMPLS control
plane to address those requirements.

END




General Comments (no particular section)

1. Given that this document is providing the detail for the requirements in 
7025, it might be advantageous to the reader to structure the document 
according to the requirements listed in 7025.



[MC] Sections following RFC7025 structure is added to the introduction.



2. The document gives a sparse highlight of what extensions are needed and why 
Section 1 and then launches into the details in section2 and on.  More 
elaboration on motivation and gaps and requirements would be helpful to better 
understand why the extensions are needed.

 [MC] New section describing the requirements and where extensions are
needed is added


3. This should be liaised to ITUT SG15 Q12 and Q14 for review.  Maybe Q11/15 
too.



[MC] No additions to what Deborah indicated.


Sec 1.2 - RFC 7025 has 13 different requirements listed.



1. Why are they repeated here and not simply referenced? One must have both 
documents to fully understand the requirements this document is addressing, so 
there is no need to restate (and possibly misstate) the agreed requirements 
here for readability



[MC] The intent is to summarize the requirements (which are referenced
in Section 2), this has been changed on -13


2. Why is this only a subset of the requirements in RFC 7025?  Is there less 
covered here than in RFC7025?  If so this must be spelled out in terms of 
coverage.  Perhaps a table to explain the functions noted in 7025 vs what this 
document covers.


 [MC] There is less covered than RFC7025 because some of those
requirements are addressed by RFC8282, Tables for RFC7025 section 3.1
and section 3.2 will be added to better indicate:
  - Which requirement is already covered in existing docume

Re: [Pce] Opsdir last call review of draft-ietf-pce-gmpls-pcep-extensions-12

[Cyril Margaria]

Thanks a lot for your review,

please find answers inline, a revised ID will be posted shortly


From: Tianran Zhou 
Sent: Monday, November 26, 2018 19:52
To: ops-...@ietf.org
Cc: draft-ietf-pce-gmpls-pcep-extensions@ietf.org; pce@ietf.org; 
i...@ietf.org
Subject: Opsdir last call review of draft-ietf-pce-gmpls-pcep-extensions-12

Reviewer: Tianran Zhou
Review result: Has Issues

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

I did not see any special operational or network management related issue. But
I saw some other issues.

Major:
This document includes too many Terms and Acronyms without explanation nor
expansion. Most of them are specific to GMPLS/transport network. I strongly
suggest the authors can have a Terms section to explain them all.

[MC] A Terminology section is added

Minor:
It seems the abstraction is too simple with just one sentence. Could you
describe a littel more about the what and why?

The new abstract will read:
OLD:
This memo provides extensions to the Path Computation Element
communication Protocol (PCEP) for the support of GMPLS control plane.

NEW:
 The Path Computation Element (PCE) provides path computation
 functions for Multiprotocol Label Switching (MPLS) and Generalized
 MPLS (GMPLS) networks.  Additional requirements for GMPLS are
 identified in [RFC7025] .

This memo provides extensions to the Path Computation Element
communication Protocol (PCEP) for the support of the GMPLS control
plane to address those requirements.

END

Cheers,
Tianran

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

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] 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] 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] 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 a

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