Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt)

From: Julien Meuric <[email-masked]>
Date: Thu, 03 Apr 2014 16:30:01 +0200

Hi all.

This thread started to tackle an interesting issue. More feedback would 
have been much welcome.

Let me try to rephrase.
What we agree on: the WG (whatever its name) works on PCEP.
What may be discussed: is a PCE defined as "a path computation function" 
or as "a deciding end of a PCEP session"?

The former being defined in RFC 4655, I believe "splitting hairs" avoids 
ambiguity and moving forward with draft-ietf-pce-questions as it is 
would make no harm. If noone objects, we will soon start a WG LC.

Back to the latter definition, we have started to identify this boundary 
by introducing the phrases "passive PCE" (i.e. legacy definition) and 
"active PCE". This looks like an oxymoron to refer to a "PCEP-based LSP 
coordinator", but PCE is growing up, it is no longer as small as it used 
to be. Confusion is there, but it is quite common for evolving 
technologies. Sometimes, I still struggle with some people who 
understand MPLS as LDP-signalled only and leave MPLS-TE out of MPLS; 
with some others to explain that an IGP-TE is not just a routing 
protocol but a TED synchronization mechanism...

Bottom line: more than ever, we must make sure in our documents that the 
terms are correctly defined and put some effort in avoiding the 
ambiguity related to that vocabulary transition/extension.

Alternate path: should we be able to get consensus on a less ambiguous 
term, we might search&replace all "active PCE" instances (the phrase is 
not RFC yet)...
[Chair hat off] Most of the "accurate" phrases I could think of are too 
long to be successful, but I'm not a native speaker.

Regards,

Julien

Mar. 18, 2014 - Adrian Farrel:
> Dhruv,
> How right you are: a decision is needed and the WG should discuss it.
>
> I suspect it will not help us to quote one draft or another, because we are
> trying to converge on consensus from a variety of work-in-progress documents.
>
> *The* crunch from my perspective is whether a PCE is a provisioning source or
> not. Please note that this is a very different question from whether PCEP can be
> used as a provisioning protocol.
>
> RFC 4655 has:
>     PCE: Path Computation Element.  An entity (component, application, or
>     network node) that is capable of computing a network path or route
>     based on a network graph and applying computational constraints.
>
> The debate, I suppose, is about whether we stick with that definition, or
> broaden it. I would personally prefer to draw boxes around functional
> components. Thus, from my point of view, what is being discussed is a variant of
> Figure 5 from RFC 4655. In that variant, the PCE is a component of the NMS, and
> the NMS uses PCEP as the service request protocol. This vision keeps the concept
> of a PCE as a simple computation engine, and allows all of the rest of the
> function as before.
>
> One might draw the following ASCII Art...
>
> <font non-proportional>
>           -----------------------------------
>          |                  ------   -----   |
>          | NMS             |LSP-DB| | TED |<-+----------->
>          |                / ------   -----   |  TED synchronization
>          |  -------------/    |        |     |  mechanism (for example,
>          | | LSP         |    |        |     |  routing protocol)
>          | | Coordinator |    v        v     |
>          | |             |  --------------   |
>          | |             |-|     PCE      |  |
>          |  -------------   --------------   |
>          |         |               |         |
>          |    ---------------------------    |
>          |   |    PCEP Protocol Engine   |   |
>          |    ---------------------------    |
>          |       |     A                     |
>          |       |     |                     |
>           -------+-----+---------------------
>     Provisioning |     |Computation
>          Request |     |Request/Response
>                  V     V
>                 ----------    Signaling    ----------
>                | Head-End |   Protocol    | Adjacent |
>                |  Node    |<------------->|   Node   |
>                 ----------                 ----------
> </font>
>
> Now, draft-ietf-pce-pce-initiated-lsp currently says...
>
>     A PCC or PCE indicates its ability to support PCE provisioned dynamic
>     LSPs
>
> And I think this is a little confused. I think it is referring to the use of
> PCEP for provisioning LSPs.
>
> Maybe I am splitting hairs, or maybe I am trying to ensure that new work remains
> consistent with the architecture without preventing any of the new work.
>
> In my opinion the use of terms in the new work has conflated what we implement
> and sell as a PCE (wonderful, glowing marketing term), and what the functional
> components are. This debate as one of the primary reasons why I started
> draft-ietf-pce-questions, so I would clearly like to see it resolved.
>
> Thanks,
> Adrian
>
>
> From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
> Sent: 18 March 2014 06:24
> To:[email-masked]
> Subject: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action:
> draft-ietf-pce-questions-02.txt)
>
> WG,
>
> Regarding PCE-Initiated LSP.
>
> (1)http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20
> use the term "suggest" or "recommend" LSP and considers "LSP Instantiation" as
> out of scope.
>
> (2)http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00
> http://tools.ietf.org/html/draft-ali-pce-remote-initiated-gmpls-lsp-03  (WG -00
> yet to be posted)
> http://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-01
> all use the term "LSP instantiation" for PCE-Initiated LSP.
>
> We need to come to some consensus regarding this and use the same terminology
> across WG documents.
>
> Thoughts?
>
> Dhruv
>
>
> ---------------------------------------------------------------
> Dhruv Dhody
> System Architect,
> Huawei Technologies India Pvt. Ltd.,
> Banagalore
> 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: Adrian Farrel [mailto:[email-masked]]
> Sent: 17 March 2014 17:11
> To: Dhruv Dhody
> Cc:[email-masked]; 'Dhruv Dhody'
> Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-02.txt
>
> Sorry for the HTML, but I am hoping this thread can be closed soon.
>
> You're killing me :-)
> Hoping you are not red/green colourblind.
>
> Look in line for [DD].
>
> [Snipped to only the points for discussion]
>
> * Sec 5.  How Do I Select Between PCEs?
> Along with capability, you can also mention the PCE's preference for each
> computation scope as carried in the PATH-SCOPE subtlv.
>
> You are going to have to remind me, I'm afraid. Where is the PATH-SCOPE subtlv
> defined?
> I suppose I was considering that a PCC is only going to choose a PCE in its own
> domain, but I can add a note.
> [DD] Its in RFC5088, 5089, the idea being PCC should select the PCE in its own
> domain which matches with the path computation scope (inter-area, inter-AS,
> inter-layer) along with the capability.
>
> Ah, ah, ah! I was busy thinking this was a PCEP sub-tlv.
>
> OLD:
>     When more then one PCE is discovered or configured, a PCC will need
>     to select which PCE to use.  It may make this decision on any
>     arbitrary algorithm (for example, first-listed, or round-robin), but
>     it may also be the case that different PCEs have different
>     capabilities, in which case the PCC will want to select the PCE most
>     likely to be able to satisfy any one request.  The first requirement,
>       of course, is that the PCE can compute paths for the relevant domain.
> NEW:
>     When more than one PCE is discovered or configured, a PCC will need
>     to select which PCE to use.  It may make this decision on any
>     arbitrary algorithm (for example, first-listed, or round-robin), but
>     it may also be the case that different PCEs have different
>     capabilities and path computation scope, in which case the PCC will
>     want to select the PCE most likely to be able to satisfy any one request.
>       The first requirement, of course, is that the PCE can compute paths for
>       the relevant domain.
>
> Yeah, OK for that. It duplicates the final sentence I added to this paragraph,
> but it does no harm.
>
> * Sec 20.  Comparison of Stateless and Stateful PCE
> Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 is now a
> WG draft.
>
> Mutter!
> Which document is right?
> What specific issue are you raising?
> [DD]http://tools.ietf.org/html/draft-ietf-pce-questions-03#section-20  says
>                                | Stateless |  Stateful |
>        ------------------------+-----------+-----------+
>        Passive                 |     1     |     2     |
>        Active delegated LSPs   |     3     |     4     |
>        Active suggest new LSPs |     5     |     6     |
>          Active instantiate LSPs |     7     |     7     |
>
>        7. These modes are out of scope for PCE as currently described.
>
> Where does draft-ietf-pce-pce-initiated-lsp fits in, in my reading this was 7,
> and thus I suggested it should not be out of scope.
> If you agree, ignore below text.
>
> Otherwise we have some confusion over the terms.
> IMO 'Suggest new LSP' was same as PCE sends an update message triggering setup
> of a new LSP in MBB fashion.
> 'Instantiate LSP' was PCE send an LSP initiate message to instantiate an LSP.
> (7)
> Maybe you can clarify what is your understanding of these terms.
>
> OK, the difference I am trying to arrive at is whether the Active PCE can
> *require* the establishment of an LSP, or whether it is *suggesting* it.
>
> The difference is (IMHO) between an NMS or CLI that dictates what the LSR does,
> and an Active PCE that requests the LSR to act.
> More precisely, absent access controls, an LSR obeys the NMS, but an LSR can
> implement policy to filter or modify requests from a PCE.
>
> I realise that this view might not be popular with implementers of Active PCEs,
> but I think that they are failing to distinguish between the blob of code they
> are writing and naming "Company Foo's most Excellent Active PCE", and the
> architectural components.  This, at least, is part of what I am trying to convey
> in Section 19 of this document and in the ABNO document.
>
> The bottom line, I think, is that a PCE is not a provisioning tool, it is a path
> computation element. The fact that PCEP is used as a provisioning protocol does
> not make the thing that does the provisioning into a PCE.
>
> Of course, I don't want to go against consensus with this, but I do think it is
> an important architectural principle. Thus, I have been looking for words that
> suit both viewpoints...
>
> For an Active PCE to "suggest new LSPs" or to "recommend new LSPs" as described
> in Sections 19 and 20 allows, IMHO, an LSR to have a policy that says "always do
> what is recommended" and so achieving PCE-initiated LSPs. Yet, these words also
> allow a policy of "look both ways before crossing the road" which fits more
> closely with my world-view.
>
> >From my perspective "sending an update message to trigger setup of a new LSP in
> MBB fashion" is no different from setting up any other LSP. First there was no
> LSP, then there is one. So I think the distinction you are drawing doesn't work.
>
> I hope that explains my motivation, and I believe the words in the draft fit
> this explanation.
>
> Cheers,
> Adrian
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 3 Apr 2014 21:09:58 +0530

Hi Julien n All,

(1) Considering the definition of active PCE as per
http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-17

   An Active PCE is one that issues provisioning "recommendations" to
   the network.  These recommendations may be new routes for existing
   LSPs, or routes for new LSPs.

So active PCE allows delegation of LSP and PCE can make recommendations for
new routes. Further it also can recommend routes for new LSP (i.e.
PCE-Initiated LSP).

IMO, so far this might be inline with other stateful I.D.s and would
require just some minor tweak perhaps.

So the first question to the WG would be - are we happy with these terms or
should be find new ones as Julien suggested?

(2) http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20
says 'instantiate' as out of scope.

And PCE-Initiated I.D.s use the word 'instantiate' to mean "recommend new
LSP".
So the second question would be - whats a right term for this?

I hope the word-smiths in the WG can come up with something that we can
build consensus around.

Regards,
Dhruv

On Thu, Apr 3, 2014 at 8:00 PM, Julien Meuric <[email-masked]>wrote:

> ambiguity and moving forward with draft-ietf-pce-questions as it is would
> make no harm. If noone objects, we will soon start a WG LC.
>
> coordinator", but PCE is growing up, it is no longer as small as it used to
> be. Confusion is there, but it is quite common for evolving technologies.
> Sometimes, I still struggle with some people who understand MPLS as
> LDP-signalled only and leave MPLS-TE out of MPLS; with some others to
> explain that an IGP-TE is not just a routing protocol but a TED
> synchronization mechanism...
>
> terms are correctly defined and put some effort in avoiding the ambiguity
> related to that vocabulary transition/extension.
>
> term, we might search&replace all "active PCE" instances (the phrase is not
> RFC yet)...

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Apr 2014 17:42:35 +0100

Nice summary, Dhruv.
 
The reason why I didn't like "instantiate" was because it conveys (to me) more
force than "recommendation."
 
Of course "recommend instantiation" might be fine, and we could use it in both
documents.
 
Adrian
 
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 03 April 2014 16:40
To: Julien Meuric
Cc: [email-masked]
Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action:
draft-ietf-pce-questions-02.txt)
 
Hi Julien n All,

 
So active PCE allows delegation of LSP and PCE can make recommendations for new
routes. Further it also can recommend routes for new LSP (i.e. PCE-Initiated
LSP). 
 
IMO, so far this might be inline with other stateful I.D.s and would require
just some minor tweak perhaps.

 
And PCE-Initiated I.D.s use the word 'instantiate' to mean "recommend new LSP". 
So the second question would be - whats a right term for this? 
 
I hope the word-smiths in the WG can come up with something that we can build
consensus around. 
 
Regards,
Dhruv

On Thu, Apr 3, 2014 at 8:00 PM, Julien Meuric <[email-masked]> wrote:
Hi all.

This thread started to tackle an interesting issue. More feedback would have
been much welcome.

Let me try to rephrase.
What we agree on: the WG (whatever its name) works on PCEP.
What may be discussed: is a PCE defined as "a path computation function" or as
"a deciding end of a PCEP session"?

The former being defined in RFC 4655, I believe "splitting hairs" avoids
ambiguity and moving forward with draft-ietf-pce-questions as it is would make
no harm. If noone objects, we will soon start a WG LC.

Back to the latter definition, we have started to identify this boundary by
introducing the phrases "passive PCE" (i.e. legacy definition) and "active PCE".
This looks like an oxymoron to refer to a "PCEP-based LSP coordinator", but PCE
is growing up, it is no longer as small as it used to be. Confusion is there,
but it is quite common for evolving technologies. Sometimes, I still struggle
with some people who understand MPLS as LDP-signalled only and leave MPLS-TE out
of MPLS; with some others to explain that an IGP-TE is not just a routing
protocol but a TED synchronization mechanism...

Bottom line: more than ever, we must make sure in our documents that the terms
are correctly defined and put some effort in avoiding the ambiguity related to
that vocabulary transition/extension.

Alternate path: should we be able to get consensus on a less ambiguous term, we
might search&replace all "active PCE" instances (the phrase is not RFC yet)...
[Chair hat off] Most of the "accurate" phrases I could think of are too long to
be successful, but I'm not a native speaker.

Regards,

Julien

RFC 4655 has:

<font non-proportional>
                ----------    Signaling    ----------

Thanks,
Adrian

To:[email-masked] <mailto:[email-masked]> 

WG,

Thoughts?

Dhruv

Cc:[email-masked] <mailto:[email-masked]> ; 'Dhruv Dhody'

You're killing me :-)

Look in line for [DD].

OLD:

Mutter!
Which document is right?

Cheers,
Adrian