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 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Ramon Casellas 发送时间: 2012年7月13日 18:20 收件人: pce@ietf.org 主题: Re: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt On 07/13/2012 11:02 AM, Fatai Zhang wrote: 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. 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
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
