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

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

Hi again,
 
Here is the second missed email.
 
Thoughts in line.
 
Cheers,
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv
Dhody
Sent: 06 February 2014 12:22
To: Farrel Adrian
Cc: [email-masked]
Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-02.txt
 
Hi Adrian, 
 
There are a few comments that i made during the WG adoption call. 
[http://www.ietf.org/mail-archive/web/pce/current/msg03168.html]. 
 
Most of them have been handled in -01 version. 
I have listed some that i would like your opinion on. 
 
* Sec 3.  How Is Topology Information Gathered?   
Another issue faced when using IGP to fed TED is the area-scope issue. Since
IGP-TE flooding scope is per area, an multi-area or AS-scope PCE must have an
IGP peer
for all the areas. 
 
I'm pretty sure I disagree or agree.
You are saying that a PCE that has multi-domain visibility must be able to build
its TED from multiple sources (i.e. from each domain). 
Isn't this obvious?
But I am adding a simple note at the end of Section 3 to cover this case.
 
Also I think we can augment this section to include 'How PCE learn about
Boundary Nodes?'. 
 
Hmmmm. And sigh :-)
How does a non-PCE system learn about boundary nodes?
It's in the IGP and the EGP.
 
* 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.
 
* Sec 13.  What are Sticky Resources?
OLD:
This can result in LSP setup failures are there is contention for
resources.
NEW:
This can result in LSP setup failures if there is contention for
resources.
 
Ack
 
* 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?
 
Thanks,
Adrian (who hates html email, but can't be bothered to convert this one to plain
text).

---

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

Hi Adrian,

Sorry for the HTML, but I am hoping this thread can be closed soon...

Look in line for [DD].

From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 17 March 2014 03:28
To: 'Dhruv Dhody'
Cc: [email-masked]
Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-02.txt

Hi again,

Thoughts in line.

Cheers,
Adrian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 06 February 2014 12:22
To: Farrel Adrian
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-02.txt

Hi Adrian,

IGP-TE flooding scope is per area, an multi-area or AS-scope PCE must have an IGP peer

for all the areas.

You are saying that a PCE that has multi-domain visibility must be able to build its TED from multiple sources (i.e. from each domain).

Isn't this obvious?

[DD] I am happy with the note!

Boundary Nodes?'.

Hmmmm. And sigh :-)

[DD] Sorry for being a pain, but I can live with you not including this.

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.

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.

(snip)

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?

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

Regards,

Dhruv

Thanks,

Adrian (who hates html email, but can't be bothered to convert this one to plain text).

---

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

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]

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:
 
Yeah, OK for that. It duplicates the final sentence I added to this paragraph,
but it does no harm.

Mutter!
Which document is right?

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

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 18 Mar 2014 06:23:55 +0000

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

You're killing me :-)

Look in line for [DD].

OLD:

NEW:

     the relevant domain.

Yeah, OK for that. It duplicates the final sentence I added to this paragraph, but it does no harm.

Mutter!

Which document is right?

                              | Stateless |  Stateful |

      Passive                 |     1     |     2     |

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Mar 2014 10:49:33 -0000

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!

Sorry for the HTML, but I am hoping this thread can be closed soon…

You're killing me :-)

Look in line for [DD]. 

OLD:

Mutter!
Which document is right?

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… 

Cheers,
Adrian

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 18 Mar 2014 12:11:51 +0100

> How right you are: a decision is needed and the WG should discuss it.

Agree, more discussions always good for WG.

> trying to converge on consensus from a variety of work-in-progress

I think relating discussions and consensus to consistent documents is
important for best progress. Any confusion between what we think/mean
and what we document SHOULD be solved in our WG documents within thoes
documents.

> broaden it.

We can stick to definition only if it is not confusing.

> I would personally prefer to draw boxes around functional
> components.

That needs to be added maybe in the questioning drafts or unanswered issues.

> consistent with the architecture without preventing any of the new work.

If architecture needs adjusting it is easier to adjust, and make
consistent with new documents. So I think that Dhruv's suggestion may
be closer to that.

> draft-ietf-pce-questions, so I would clearly like to see it resolved.

Is it ok to leave the marketing terms as it is, but we only adjust the
terms' use and definitions, as Dhruv's suggested. However, documents
should be without confusing/mismatch when describing implemented
terms/technologies.

Regards,
AB

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 19 Mar 2014 08:12:54 +0100

Adrian, all

A somehow orthogonal comment/question unrelated to whether a PCE should 
be kept a simple element for path computation (as in abno) or its scope 
augmented with NMS-like capabilities. I am wondering about the role of 
your "PCEP Protocol Engine" box, as simply opposed to have two parallel 
vertical lines that use PCEP.  Maybe a away of narrowing my question 
would be as follows:

"Can it be that the whole NMS box in your drawing is a single IP host?"

If the answer is, as I would expect "usually not", since the LSP 
coordinator and PCE are different functional entities that can be 
located in different IP hosts, then I guess my subsequent comment would 
be that "the PCEP protocol engine box" is not really needed, the same 
way we don't add "X protocol engine" to all the interfaces / lines.

However, in my humble opinion, it does make sense if, for example, the 
NMS is just an IP host, and to highlight the role of PCE as a functional 
component within that box. In this case, I am wondering about the issue 
with RFC5440 disallowing parallel PCEP sessions [1] (this is something 
that I find unfortunate in RFC5440, and that was left out of the errata 
when we changed the mandatory client port)

In other words, If the head end node has a single, unique, persistent 
PCEP/TCP connection to the "NMS" box, represented by a given IP address, 
and which is used for path computation requests and responses, can this 
persistent PCEP session be *also* used to receive provisioning requests? 
(i.e. multiplexed in a single PCEP instance). By RFC5440 the answer 
seems to be "yes". Then your question reduces to "shall the working 
group call PCE to the NMS box, of just to the inner box", but noting 
that the only thing that is added to a PCE is the "LSP coordinator function"

Alternatively, I guess that the head end node would need to listen for 
incoming TCP/PCEP connections as provisioning interface or establish a 
PCEP connection with the "LSP coordinator" (thus assuming configuring 
the head end node with both addresses), in addition to acting as PCC 
client.

(I am postponing the issue of having to replicate PCRpts to both the 
initiating LSP coordinator as well as PCE, and keeping both in sync for 
a later discussion :o)

sorry for the long, I guess somehow  confusing mail.

R.

         | NMS|LSP-DB|  | TED |<-+----------->
                ----------    Signaling    ----------

[1] RFC5440 Only one PCEP session can exist between a pair of PCEP peers at any
    one time.  Only one TCP connection on the PCEP port can exist between
    a pair of PCEP peers at any one time.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 19 Mar 2014 08:15:35 +0000

Hi, Ramon,

I think you raise a very good point.  IMHO, the two lines drawn (using the figure Ramon provided below) between the box above (named as NMS) and NEs will not co-exist although it serves the purpose of including all modes currently under discussion.

1)      For provisioning, as detailed in http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00, it does not expect any computation request/reply message exchange (if I understand correctly) since LSPs are assumed to be delegated all the time. So, although I do expect other PCEP messages other than PCInitiate sent through, but definitely not request and reply communication exchanged.

2)      For computation request/reply, assume what we meant here is the basic stateless (or maximum the active stateful PCE) function, then the left line is definitely not needed.

A couple of more points I would like to raise for discussion:
First: PCEP is used between a PCE and a PCC, but from figure below it seems PCEP can also be used between a LSP coordinator and a NE, or say a NMS and a NE.
Second: Currently in Section 5.5 of RFC4655, it discuss how NMS can take advantage of a PCE, but again there NMS and PCE are different boxes and the NMS is acting as a PCC and presumably using its own protocol (but not PCEP) for service request.

So, it seems that we need to either broaden PCE function or broaden the entity catalogue using PCEP, isn’t it?

(To answer Dhruv’s question sent to the list) Personally, I do not have an issue saying phrases such as “PCE-initiated LSP” since we are extending the PCEP to do provisioning and the acting entity has to be PCE in current std definition, unless I am mistaken. If preserving current function of PCE (aka, path computation) is preferred, what we can emphasize is the PCE itself is not acting as a provisioning entity but rather it acts as a proxy for the entity (say a network controller) to send the provisioning request. So, instead of controller->PCE->controller-> NE message flow, it is simplified as controller->PCE->NEs path.

Regards,
Xian

From: Pce [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: 2014年3月19日 15:13
To: 'Adrian Farrel' ([email-masked]); pce >> "[email-masked]"
Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt)

Adrian, all

A somehow orthogonal comment/question unrelated to whether a PCE should be kept a simple element for path computation (as in abno) or its scope augmented with NMS-like capabilities. I am wondering about the role of your "PCEP Protocol Engine" box, as simply opposed to have two parallel vertical lines that use PCEP.  Maybe a away of narrowing my question would be as follows:

If the answer is, as I would expect "usually not", since the LSP coordinator and PCE are different functional entities that can be located in different IP hosts, then I guess my subsequent comment would be that "the PCEP protocol engine box" is not really needed, the same way we don't add "X protocol engine" to all the interfaces / lines.

However, in my humble opinion, it does make sense if, for example, the NMS is just an IP host, and to highlight the role of PCE as a functional component within that box. In this case, I am wondering about the issue with RFC5440 disallowing parallel PCEP sessions [1] (this is something that I find unfortunate in RFC5440, and that was left out of the errata when we changed the mandatory client port)

In other words, If the head end node has a single, unique, persistent PCEP/TCP connection to the "NMS" box, represented by a given IP address, and which is used for path computation requests and responses, can this persistent PCEP session be *also* used to receive provisioning requests? (i.e. multiplexed in a single PCEP instance). By RFC5440 the answer seems to be "yes". Then your question reduces to "shall the working group call PCE to the NMS box, of just to the inner box", but noting that the only thing that is added to a PCE is the "LSP coordinator function"

Alternatively, I guess that the head end node would need to listen for incoming TCP/PCEP connections as provisioning interface or establish a PCEP connection with the "LSP coordinator" (thus assuming configuring the head end node with both addresses), in addition to acting as PCC client.

(I am postponing the issue of having to replicate PCRpts to both the initiating LSP coordinator as well as PCE, and keeping both in sync for a later discussion :o)

R.

        |                  ------   -----   |

        | | Coordinator |    v        v     |

        | |             |  --------------   |

        | |             |-|     PCE      |  |

        |         |               |         |

        |       |     A                     |

        |       |     |                     |

                V     V

               ----------    Signaling    ----------

               ----------                 ----------