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: 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: [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
