Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 16 Mar 2014 21:12:30 -0000

Hi Dhruv,

Doing my archivist's job for her, I find two emails from you not responded.

Sorry.

Herewith, number 1

A

> -----Original Message-----
> From: Dhruv Dhody [mailto:[email-masked]]
> Sent: 03 October 2013 10:40
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-01.txt
> 
> Hi,
> 
> Some comments inline!
> 
> Also I made comments during the adoption call [http://www.ietf.org/mail-
> archive/web/pce/current/msg03168.html]. Some of the editorial comments have
> been handled and would like to know the Author's opinion on the rest.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Adrian Farrel
> > Sent: 02 October 2013 20:42
> > To: [email-masked]
> > Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-01.txt
> >
> > Hi,
> >
> > I did an update to this I-D to clean up the typos and references. No new
text
> > of substance.
> >
> > It would be really good if people could comment on which issues are not
clear,
> > and also suggest additional questions to be answered by the document.
> >
> > During the discussion of adoption by the WG, Xian said:
> >
> (snip)
> >
> > > 2: In Section 3, it states
> > >  "Note that this exchange of PCE capabilities is in the form of an
> > >    announcement, not a negotiation.  That is, a PCC that wants specific
> > >    function from a PCE must examine the advertised capabilities and
> > >    select which PCE to use for a specific request.  There is no scope
> > >    for a PCC to request a PCE to support features or functions that it
> > >    does not offer or announce."
> > >
> > > From what we currently have in Section 5.3 of draft-ietf-pce-stateful-
> > > pce-04, it seems to me that LSP modification capability is negotiated
> > > *not* advertised.
> > > The reason is obvious since it is a two-way thing. Just wonder whether
> > > phrase likes "stateful PCE capability negotiation" in the WG draft or the
> > > text above should be modified to avoid confusion?
> >
> > I went back and read section 5.3 of the -06 version of the draft. I agree
> > that the PCE and PCC "negotiate" which functions they are going to use, but
> > only in the sense that they each say whether they support the features and,
> > if they both do, they agree to use them. Thus, just as with PCEP
pre-stateful
> > extensions, the speakers are announcing their capabilities, not requesting a
> > service of choosing from a set of available features. I reckon that doesn't
> > count as negotiation.
> >
> > Thoughts?
> >
> [DD] I agree! And I suggest [draft-ietf-pce-stateful-pce] section 5.3 should
be
> renamed to Capability Advertisement.

OK, but out of scope for this document

> > > 3: Section 18, it states
> > >    LSP delegation [I-D.ietf-pce-stateful-pce] is the process where a PCC
> > >    (usually an ingress LSR) passes responsibility for triggering
> > >    reoptimization or re-routing of an LSP to the PCE."
> > >
> > > LSP delegation covers wider purpose than stated above, right? For
> > > example providing protection paths, as described in draft-ietf-pce-
> > > stateful-pce-00.
> >
> > I don't agree with this.
> > Delegation (according to the -06 version) grants the PCE rights to modify
the
> > parameters of an LSP.
> > I don't see how this is related to providing protection paths.
> > I suppose that one could set up two LSPs without worrying about whether they
> > share resources, and then delegate them to the PCE to sort them out and make
> > them disjoint. Seems a bit extreme to me.
> >
> > Furthermore, section 5.7 of draft-ietf-pce-stateful-pce-06 says...
> >
> >    LSP protection and interaction with stateful PCE, as well as the
> >    extensions necessary to implement this functionality will be
> >    discussed in a separate draft.
> >
> [DD]Going back to the original text (and not focusing on protection), I
mentioned
> in my earlier mail...
> 
>      This sections gives an impression that the delegation of LSP
>      can only be done once the LSP is setup and then LSR (PCC) passes
>      responsibility for triggering reoptimization or re-routing of an
>      LSP to the PCE. In case of a new tunnel configuration with
>      delegation enabled, IMHO the PCC should be able to delegate
>      even when it has no path right now.
> 
> I suggest rewording to not limit delegation to "passing responsibility for
triggering
> reoptimization or re-routing".
> Maybe use the wording of the draft-ietf-pce-stateful-pce-06:
> 
>      "LSP delegation [I-D.ietf-pce-stateful-pce] is the process where
>       a PCC (usually an ingress LSR) grants the right to update LSP
>       attributes of an LSP to the PCE."

Well, I don't call that delegation. Others may disagree, but I don't see any
difference between what you described as "delegation before LSP establishment"
and any other request to the Active PCE to cause an LSP to be set up.

I think there is also some subtlety in the text you quoted from the stateful PCE
draft. Is a PCC obliged to act on the update it receives from a PCE? I think
there is always the case where the PCC tries to act, but fails for some reason
(for example, there has been a change in the network in the meantime). So we
have the possibility for the PCC to say "sorry, but no." So the only question is
whether the PCC can say that for its own reasons. I believe the answer is "yes"
and the magic unicorn in this picture is called "Policy".

A

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 17 Mar 2014 09:08:35 +0000

Hi Adrian, 

(snip to the only open issue here)

> I think there is also some subtlety in the text you quoted from the stateful
> PCE draft. Is a PCC obliged to act on the update it receives from a PCE? I
> think there is always the case where the PCC tries to act, but fails for some
> reason (for example, there has been a change in the network in the meantime).
> So we have the possibility for the PCC to say "sorry, but no." So the only
> question is whether the PCC can say that for its own reasons. I believe the
> answer is "yes"

[DD] I agree with this and I see that you have added text in -03 version. 
But my concern is with the fact that the current section only talks about "re-optimization or re-routing". 
As you also mention that, there might be 'delegation' before LSP establishment and thus I was thinking something in line of....

OLD:
LSP delegation [I-D.ietf-pce-stateful-pce] is the process where a PCC
(usually an ingress LSR) passes responsibility for triggering
reoptimization or re-routing of an LSP to the PCE.  In this case, the
PCE would need to be both Stateful and Active.

NEW:
LSP delegation [I-D.ietf-pce-stateful-pce] is the process where a PCC
(usually an ingress LSR) grants the right to suggest updates to LSP attributes 
of an LSP to the PCE. In this case, the 
PCE would need to be both Stateful and Active.

... so that it doesn't limit to re-optimization/re-routing as well as only 'suggest' updates! 
I hope this change is reasonable? 

Regards,
Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Mar 2014 11:23:44 -0000

Hi,

[snip]

> As you also mention that, there might be 'delegation' before LSP establishment
> and thus I was thinking something in line of....
> 
> OLD:
> ... so that it doesn't limit to re-optimization/re-routing as well as only
'suggest'
> updates!

OK, I get your point.

A