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:ramon.casel...@cttc.es]
发送时间: 2012年7月16日 17:12
收件人: Fatai Zhang
抄送: pce@ietf.org
主题: 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
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to