Subject: [Pce] I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

From: [email-masked]
Date: Fri, 13 Jul 2012 01:54:57 -0700

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           : Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
	Author(s)       : Eiji Oki
                          Tomonori Takeda
                          Adrian Farrel
                          Fatai Zhang
	Filename        : draft-ietf-pce-inter-layer-ext-07.txt
	Pages           : 19
	Date            : 2012-07-13

Abstract:
   The Path Computation Element (PCE) provides path computation
   functions in support of traffic engineering in Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   MPLS and GMPLS networks may be constructed from layered service
   networks. It is advantageous for overall network efficiency to
   provide end-to-end traffic engineering across multiple network layers
   through a process called inter-layer traffic engineering. PCE is a
   candidate solution for such requirements.

   The PCE communication Protocol (PCEP) is designed as a communication
   protocol between Path Computation Clients (PCCs) and PCEs. This
   document presents PCEP extensions for inter-layer traffic engineering.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-inter-layer-ext-07

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pce-inter-layer-ext-07

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

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 13 Jul 2012 09:02:13 +0000

Hi all,

A new version has been submitted. Only one change:

Introduce a new PCEP object (SERVER-INDICATION) to replace ERO subobject in Section 3.5, because one comment was raised that ERO subobject should defer to CCAMP extension (RSVP-TE extension).

Please review this draft for details.

Thanks

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2012年7月13日 16:55
收件人: [email-masked]
抄送: [email-masked]
主题: [Pce] I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

Abstract:

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 13 Jul 2012 12:20:06 +0200

> Please review this draft for details.
Hi Fatai, authors,

Thanks for updating the draft, just a couple of questions, quoting:

PCE MAY specify the server layer path information in the ERO. In this
case, the requested PCE replies a PCRep message that includes at least
two sets of ERO information in the path-list, one is for the client
layer path information, and another one is the server layer path
information. When SERVER-INDICATION is included in a PCRep message, it
indicates that the path in the ERO is the server layer path information.

Q1)
for clarification, I take it that it is still possible that the "SERVER
layer" part or segment can still be provided simply "embedded" in a
single ERO that includes both layers, right? i.e. a single strict ERO in
a MRN/MLN and that the corresponding region border node is responsible
for detecting the far end etc. In other words, the use case where a
single ERO includes both client and server layers (in a single path)
would be ok, and not against the quoted paragraph: The response includes
only 1 ERO A B C a b c d e D E F and, (optionally), a second path with
ERO C a b c d e D + SERVER_INDICATION. (Before the update, we used A B C
X a b c d e X D E F to "tag" region changes if needed). I take it the
new text means "A PCE MAY specify both the client and server layers
separately, in dedicated EROs. In this case..." is this right?

A --- B --- C ============= D --- E -- F
| |
a -- b -- c -- d -- e

Q2)
Also, assume A is the higher layer LSP (A --> F) ingress node and the
PCC, and a H-LSP / FA will be stablished when the high layer Path
reaches C. Assume A gets the PCEP response from the PCE. The issue I
have now is that how would RSVP-TE "forward" the server layer to C so it
is useful? would I need to merge the ERO?

In summary, in my implementation either:

a) I have a multi-layer ERO, without "tags" or "banners" so each node
needs to check if it is a region boundary node, and act accordingly-

b) I have a multi-layer ERO, tagged with the sub-object (until draft
-06) X. That subobject tells the ERO processing node that it is a
boundary node, and both layers are "embedded" in a single ERO.

c) I have e.g. two EROs, split on a per server basis : client and
server. How do I forward these to node C? what is the benefit of
splitting them?

Hopefully I have formulated my question clearly :)

Thanks and best regards
Ramon

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 16 Jul 2012 06:47:53 +0000

Hi Ramon,

For Q1, it could be possible to return two EROs as what you said, but my intention is to return two EROs like: ERO-client: A-B-C-D-E-F, and ERO-Server: C-a-b-c-d-e-f-D+ SERVER_INDICATION; In this way, it can reduce the overlapped information.

For Q2, the PCEP extension does not exert on how to signal the RSVP-TE.  This draft only focuses on how to return the computed path, but how to create the computed path through signaling is out of scope of this draft (this is reason of the update that is to decouple the dependency betweeen PCEP and RSVP-TE extention). The PCC could be either head node or NMS. For example, if PCC is NMS, then NMS can configure the server LSP first (and then client LSP) from the returned path manually or dynamically. Therefore, actually, the three alternatives you mentioned could be possible from implementation perspective. Option B is my original thought and RSVP-TE extension is described in [draft-zhang-ccamp-gmpls-h-lsp-mln]. Repeat again, how to create the computed path through signaling is out of scope of this draft.

Thanks

Fatai

发件人: [email-masked] [mailto:[email-masked]] 代表 Ramon Casellas
发送时间: 2012年7月13日 18:20
收件人: [email-masked]
主题: Re: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

Hi all,

Hi Fatai, authors,

PCE MAY specify the server layer path information in the ERO. In this case, the requested PCE replies a PCRep message that includes at least two sets of ERO information in the path-list, one is for the client layer path information, and another one is the server layer path information. When SERVER-INDICATION is included in a PCRep message, it indicates that the path in the ERO is the server layer path information.

Q1)
for clarification,  I take it that it is still possible that the "SERVER layer" part or segment can still be provided simply "embedded" in a single ERO that includes both layers, right?  i.e. a single strict ERO in a MRN/MLN and that the corresponding region border node is responsible for detecting the far end etc. In other words, the use case where a single ERO includes both client and server layers (in a single path) would be ok, and not against the quoted paragraph: The response includes only 1 ERO A B C a b c d e D E F and, (optionally), a second path with ERO C a b c d e D + SERVER_INDICATION. (Before the update, we used A B C X a b c d e X D E F to "tag" region changes if needed). I take it the new text means "A PCE MAY specify both the client and server layers separately, in dedicated EROs. In this case..." is this right?

Q2)
Also, assume A is the higher layer LSP (A --> F) ingress node and the PCC, and a H-LSP / FA will be stablished when the high layer Path reaches C. Assume A gets the PCEP response from the PCE. The issue I have now is that how would RSVP-TE "forward" the server layer to C so it is useful? would I need to merge the ERO?

a) I have a multi-layer ERO, without "tags" or "banners" so each node needs to check if it is a region boundary node, and act accordingly-

b) I have a multi-layer ERO, tagged with the sub-object (until draft -06) X. That subobject tells the ERO processing node that it is a boundary node, and both layers are "embedded" in a single ERO.

c) I have e.g. two EROs, split on a per server basis : client and server. How do I forward these to node C? what is the benefit of splitting them?

Thanks and best regards
Ramon

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 17 Jul 2012 07:35:12 +0000

Hi Ramon,

Agree. The description needs to be refined as you suggested.
===================================================================
"the SERVER-INDICATION object is mandatory if the path in the response is used to convey server layer information".

Thanks

Fatai

发件人: Ramon Casellas [mailto:[email-masked]]
发送时间: 2012年7月16日 17:12
收件人: Fatai Zhang
抄送: [email-masked]
主题: Re: 答复: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

Hi Fatai,

Thanks for the clarifications, other comments inline

On 07/16/2012 08:47 AM, Fatai Zhang wrote:
Hi Ramon,

It makes sense, but,just in case I missed it, my question was more in the line that I would also like the option to return only *one* ERO, with elements from both layers. The current text seems to indicate that if there is server layer info (which is the case if the ERO contains elements from both layers, isn't it?) It is not mandated by the text to have two EROs but just one will do.

For Q2, the PCEP extension does not exert on how to signal the RSVP-TE.

Understood.

Additionally, I also sent two more comments to the list, but apparently they got lost (sorry for the duplicates if you happen to get the mail after this one) so I copy them here

-----8<-----8<------
Two more comments / questions. To help the discussion consider the topology below, and  consider a "legacy" (rfc5440) PCC co-located in a GMPLS controller of a PSC node A which belongs to a MRN (dual layer, PSC over LSC)

      [PSC PSC]
+-----+     +------+                    +------+      +-----
| A   |-----|   B  |[PSC, LSC]          | C    |------| D
+-----+     +------o                    o------+      +-----
                    \+------+  +------+/
                     |  L1  |--| L2   |
                     +------+  +------+
                          [LSC LSC]

I) Quoting the draft: "When the INTER-LAYER object is absent from a PCReq message, the receiving PCE MUST process as though inter-layer path computation had been explicitly disallowed". I would like to understand the rationale for this, so clarification would be appreciated. why can't, say, node A, if it has a simple PCC get an interlayer ERO (A B  L1 L2 C D) if A does not support this extension? I tend to think it should be possible if B is able to detect the region change and establish the H-LSP, etc. Node A sends a PCReq = request with RP(1), ENDPOINTS(A,D), BW(1Gb/s)

In other words, if I deploy a PCE that implements pce-interlayer-ext-07 in a MRN with a unified control plane (single instance), the PCE cannot provide a strict interlayer ERO to node A if A (legacy, RFC 5440) does not include the interlayer object, but I am not sure why.

Another question / comment, more philosophical in nature, and  potential issue of backwards compatibility with draft -07:
In short, I am unsure of encoding "parts" or "segments" in one of the paths in the pathlist of the response. If we look at RFC5440

"If the path computation request can be satisfied (i.e., the PCE finds a set of paths that satisfy the set of constraints), the set of computed paths specified by means of Explicit Route Objects (EROs) is inserted in the PCRep message.  " I tend to think that, reading RFC5440, all the paths in the pathlist for the PCEP response corresponding to a given request should satisfy the constraints of the requests (and, consequently, the PCC could select any, maybe based on the metric) however, correct me if I am wrong,   the server layer path does not (for starters, the endpoints are different). Isn't this proposed extension slightly against the spirit of rfc5440?
What are your thoughts? (additionally, I wasn't able to find a procedure that describes what happens when a PCC receives a response / path with an object it does not recognize / support, specially in the case of SERVER-INDICATION). Finally, section 3.5 says that SERVER-INDICATION is optional which is, imho a bit confusing (I am aware it is optional in the sense that it may not appear for paths in the client layer). Maybe you could reword it to say something in the lines of "the SERVER-INDICATION object is mandatory if the path in the response is used to convey server layer information".

Also note that the suggested IANA allocations are already assigned except 18 iirc, by monitoring, etc.

Thanks again, and best regards
Ramon

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 17 Jul 2012 08:47:49 +0000

Hi Ramon,

More information for the response.

Version 06 describes only “one “ ERO, but it depends on ERO extension, so version 07 uses this alternative (multiple EROs when server layer path info is returned).

For Q1, in this draft, it says  “When the INTER-LAYER object is absent from a PCReq message, the receiving PCE MUST process as though inter-layer path computation had been explicitly disallowed).”, so when a PCC cannot recognize “SEVER-INDICATION” object, it will not include INTER-LAYER object in the PCReq message.  Otherwise, it means that the PCEP implementation complied to the PCEP extension defined in this draft and it can understand “SEVER-INDICATION” object.

Note that please don’t mix the PCEP protocol and RSVP protocol or data plane capability.

For Q2, agree with you.

Thanks

Fatai

发件人: Fatai Zhang
发送时间: 2012年7月17日 15:35
收件人: 'Ramon Casellas'
抄送: [email-masked]
主题: 答复: 答复: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

Hi Ramon,

Thanks

Fatai

Hi Fatai,

Understood.

-----8<-----8<------

      [PSC PSC]