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

[Fatai Zhang <[e-mail]>]

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:[e-mail]]
发送时间: 2012年7月16日 17:12
收件人: Fatai Zhang
抄送: [e-mail]
主题: 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,

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.

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.



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.


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