Hi Franz, Thanks for various comments.
Sorry that authors are a bit behind on this. We will update the document addressing your comments. Thanks, Tomonori Rambach, Franz (NSN - DE/Munich) wrote: > 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: +49-89-636-44188 > Fax: +49-89-636-45814 > > [email protected] <mailto:[email protected]> > http://www.nokiasiemensnetworks.com/global/ > > Nokia Siemens Networks GmbH & Co. KG > Sitz der Gesellschaft: Mu"nchen / Registered office: Munich > Registergericht: Mu"nchen / Commercial registry: Munich, HRA 88537 > WEEE-Reg.-Nr.: DE 52984304 > > Perso"nlich haftende Gesellschafterin / General Partner: Nokia Siemens > Networks Management GmbH > Gescha"ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke > Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen > Sitz der Gesellschaft: Mu"nchen / Registered office: Munich > Registergericht: Mu"nchen / Commercial registry: Munich, HRB 163416 > > > > ________________________________ > > From: [email protected] [mailto:[email protected]] On Behalf Of ext JP > Vasseur > Sent: Tuesday, January 06, 2009 4:53 PM > To: [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
