Re: [Pce] Working Group Last Call:draft-ietf-pce-inter-layer-frwk-09.txt

["Rambach, Franz (NSN - DE/Munich)" <[e-mail]>]

Dear WG,

Some comments/questions regarding draft-ietf-pce-inter-layer-frwk-09.txt:

Page 5, section "2. Inter-Layer Path Computation":
The document enumerats the different PCE-based path computation models, i.e. single PCE, multiple PCE with and without inter-PCE communication.
If the multi-layer path computation only incorporates two layers, the enumeration is fine. However, if a path traversing three (or more) layers is computed, also combinations of the three mentioned approaches are possible.
An example for such a combination of the different approaches: A network with three layers is given. Single PCE computation is applied for the two highest layers, i.e. for layer 3 and layer 2. Multiple PCE computation with inter-PCE communication is deployed for layer 1 and layer 2. Therefore, two PCEs - one PCE for layer 3 and layer 2 and one PCE responsible for layer 1 - are deployed in this network. For a path computation over the three layers the single PCE approach in combination with the multiple PCE computation approach is used.

I propose to add one sentence about the combination of the approaches.

Page 5/6, section "2. Inter-Layer Path Computation", paragraph about mono-layer path:
Document says: "The second case is that the PCE computes a path that includes a loose hop that spans the lower-layer network."
If a loose hop is specified, does this automatically mean, that the node before is the entry to the lower layer? This would be in contradiction to the case that a single layer path computation can include loose hops in the response and this computed path is completely setup in a single layer, i.e. the hop before the loose hop does not specify an entry point to the lower layer. 

Let's assume that a loose hop does not automatically indicate that a lower layer path should be used:
This means for the multi-layer case that the node before the loose hop, i.e. the node which expands the loose hop, does not necessarily know that it has to go into lower-layer. So, it will first ask the PCE in the higher layer and if it receives a "NO-PATH" object from the PCE, it will ask the PCE responsible for the lower layer.

Of course, another option is that in the signalling message the node before the loose hop is marked explicitly as an entry point to the lower layer. (Is such a feature already defined in the RSVP-TE protocol?)


Page 6, section "3. Inter-Layer Path Computation Models":
Document says: "As stated in Section 2, two PCE modes defined in the PCE architecture can be used to perform inter-layer path computation."
In Section "2. Inter-Layer Path Computation" three different PCE approaches were introduced (single PCE, multiple PCE with and multiple PCE without inter-PCE communication). You are summarizing the two "multiple PCE approaches (with or without inter-PCE communication)" in section two into one. Perhaps one sentence in the introduction of section 3 should state this.

Page 12, section "4.2.2 Higher-Layer Signaling Trigger Model", typo:
"Note that these actions depends on a policy being applied at the border LSR."
Should be:
"depend" instead of "depends"

Page 15, section "4.2.3. NMS-VNTM Cooperation Model":
"Note that multiple PCE path computation with inter-PCE communication does not fit in with this model."
Why does this model or the single PCE model not fit to the NMS-VNTM cooperation model?

An example how the multiple PCE with inter-PCE communication in combination with the NMS-VNTM cooperation model can look like is as follows:
	Step 1: NMS requests a path computation from PCE Hi.
	
	Step 2: PCE Hi and PCE Lo collaborate to compute a ML path. The result (H1-H2-L1-L2-H3-H4) is sent back to the NMS.
	
	Step 3: NMS discovers that lower layer links are used. NMS suggests (or requests) to VNTM that a new TE link connecting H2 and H3 would be useful. 	Furthermore, it provides one solution (H2-L1-L2-H3) for such a TE link. The NMS notifies VNTM that it will be waiting for the TE link to be created. 	VNTM considers whether the suggested lower-layer LSP or any alternative LSP connecting H2 and H3 should be established if necessary and if 	acceptable within VNTM's policy constraints.
	
	Step 4: VNTM requests the ingress LSR in the lower-layer network (H2) to establish a lower-layer LSP. The request message includes the suggested 	lower-layer LSP route obtained from the NMS.
	
	Step 5: H2 signals the lower-layer LSP.

	Step 6: If the lower-layer LSP setup is successful, H2 notifies VNTM that the LSP is complete and supplies the tunnel information.

	Step 7: H2 advertises the new LSP as a TE link in the higher-layer network routing instance.

	Step 8: VNTM notifies NMS that the underlying lower-layer LSP has been set up, and NMS notices the new TE link advertisement.

	Step 9: NMS requests H1 to set up a higher-layer LSP between H1 and H4 with the path computed in Step 2. The lower layer links are replaced by the 	corresponding higher layer TE link. Hence, the NMS sends the path H1-H2-H3-H4 to H1.

	Step 10: H1 initiates signaling with the path H2-H3-H4 to establish the higher-layer LSP.

Instead of Step 9 and 10 there is of course the possibility that analog to the example described in the draft the procedure goes on, i.e.
	Step 9': NMS again requests H1 to set up a higher-layer LSP between H1 and H4.

   	Step 10': H1 requests the higher-layer PCE to compute a path and obtains a successful result that includes the higher-layer route that is specified 	as H1-H2-H3-H4, where all hops are strict.

	Step 11': H1 initiates signaling with the computed path H2-H3-H4 to establish the higher-layer LSP.

Quite similar to the above could the single PCE approach fit with this path control model. (The only difference would be in step 2.)


Page 15, section "4.2.3. NMS-VNTM Cooperation Model":
"When the PCE fails to compute a path, it informs the PCC (i.e., head-end LSR) that notifies the NMS. The notification may include the information that there is no TE link between the border LSRs."
What happens if the PCE just returns a "NO-PATH" object and the PCE does not include any indication why no path could be found? In this case the NMS is missing the information which lower layer path is needed to establish a path between H1 and H4. So, what should the NMS do in this case?

Page 15, section "4.2.3. NMS-VNTM Cooperation Model":
If no path could be found and the request included additional constraints, e.g. the maimux delay, it is not enough that the PCE indicates which TE link in the higher layer is missing, but the PCE must also indicate which constraints such a new TE link must fullfill.
(Let's assume that in the example described in the draft a maximum delay for the path is given. In this case the PCE must indicate H1 (or NMS) which TE link is missing and it must additional indicate how much delay such a new TE link can have. If the delay is not taken into account during the path computation and path establishment of the lower layer path, it can be that even with the new TE link in the higher layer the path computation of PCE Hi fails.)
Hence, PCE Hi must exactly indicate what problems it encountered during the path computation.

Perhaps one sentence about additional constraints should be added in the description of the NMS-VNTM cooperation model


Page 18, section "5. Choosing between Inter-Layer Path Control Models":
"This section compares the cooperation model between PCE and VNTM, and the higher-layer signaling trigger model, in terms of ..."
In this chapter also the NMS-VNTM cooperation model is compared, e.g. in section "5.1 VNTM Functions". 
Add in the above sentence something like 
"This section compares the cooperation model between PCE and VNTM, the higher-layer signaling trigger model and the NMS-VNTM cooperation model in terms of ..."


Page 19, section "5.3. Complete Inter-Layer LSP Setup Time", typo:
"between PCC and PCE, PCE and VNTM, NSM and VNTM"
Instead of "NSM" it should be "NMS"

Page 20, section "5.4. Network Complexity":
"Where PCEs cooperate to determine a path, an iterative computation model such as [BRPC] can be used to select an optimal path across layers."
That's fine, but one should keep in mind that BRPC assumes that a domain sequence is given, i.e. in this case the "layer sequence". For an optimal path you must do a brute force over all possible "layer sequences" using BRPC. Since one doesn't know in advance how often the layers will be changed, the path computation can be cumbersome.

Page 21, section "5.5. Separation of Layer Management", 2nd line:
"and security concerns (see next section)."
The next section is "6. Stability Considerations". You should reference section "9. Security Considerations".

Page 22, 7. IANA Considerations, typo:
"This informaitonal" should be 
"This informational"

Page 28, in section references:
" JP. Vasseur et al, "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep, work in progress. "
Title of the draft is: "Path Computation Element (PCE) Communication Protocol (PCEP)" without "- Version 1 -"


Other general comment:
I can think of at least one other approache for a path control model sketched in the following:
Step 1: PCE(s) calculate multi-layer path. 
Step 2: Path is signalled up to the border node of the lower layer. 
Step 3: This border node asks VNTM to setup the lower layer path. The border node can provide the VNTM the exact path defined by strict hops. 
Step 4: VNTM configures the nodes of the lower layer path. 
Step 5: A new TE link is established and announced in the higher layer. 
Step 6: The border node continues to signal the path in the higher layer using the newly established TE link. 

The main point in this approach is that a network node can request a lower layer path setup from the VNTM.

This approach can can be useful if the lower-layer does not support the feature to setup a path using the control plane.

 

Best regards, 
Franz Rambach 
  
Nokia Siemens Networks GmbH & Co. KG 
COO RTP RT TAF Multi-Layer Networks & Resilience 
St.-Martin-Str. 53, Room 63.404 
D-81669 Munich, Germany 
Phone:  [phone] 
Fax:    [phone] 

[e-mail] <mailto:[e-mail]>  
http://www.nokiasiemensnetworks.com/global/ 

Nokia Siemens Networks GmbH & Co. KG 
Sitz der Gesellschaft: München / Registered office: Munich 
Registergericht: München / Commercial registry: Munich, HRA 88537 
WEEE-Reg.-Nr.: DE 52984304 

Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH 
Geschäftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke 
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen 
Sitz der Gesellschaft: München / Registered office: Munich 
Registergericht: München / Commercial registry: Munich, HRB 163416 

 

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of ext JP Vasseur
Sent: Tuesday, January 06, 2009 4:53 PM
To: [e-mail]
Subject: [Pce] Working Group Last Call:draft-ietf-pce-inter-layer-frwk-09.txt


Dear WG, 


First of all, happy new year to all of you.



This email starts a 2-week Working Group Last Call on draft-ietf-pce-inter-layer-frwk-09.txt, which will end on January 20 at noon ET.


Please send your comment on the Mailing list and to the authors.


Thanks.


JP.
_______________________________________________
Pce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pce