Hi stateful-framework-solution authors.
I did not see any reply on my previous comments I repost them, with additional
comments
I do have the following (few) comments on the documents so far:
1. (Editorial) : Section 2 Terminology :
a. The passive stateful does not use delegation, the active does. It would
be more clear to simply state this.
b. Delegation : maybe also indicate that those LSPs are named delegated
LSPs.
c. Delegation timeout : This is part of the delegation procedure, this
could be removed from the terminology
d. LSP state report : applicable to Both passive and active?, the Passive
definition could indicate that
e. LSP Update Request : for delegated LSP only,
f. LSP priority : Adding the reference to the RFC defining those values
would be useful
g. MPLS TE Global Default Restoration : This is a use-case specific term,
it would be more clear to separate it from the generic stateful terms (After
another paragraph). In addition this can also apply to GMPLS.
2. I think making the separation between the generic stateful requirement
and extensions and the "MPLS-TE/GMPLS/Others" part is a good idea, this should
also be reflected in section 2 by separating the generic terminology from the
MPLS-TE specific one.
3. Section 3: the title "Motivation and Objectives for Stateful PCE"
would fit more the objectives of the draft.
4. Section 3.1 :
OLD:
In the following sections, several use cases are described, showcasing
scenarios that benefit from the deployment of a stateful PCE.
The scenarios are specific to MPLS TE deployments, but the extensions
described in this document apply to GMPLS tunnels as well.
NEW :
In the following sections, several use cases are described, showcasing
scenarios that benefit from the deployment of a stateful PCE.
Some of the scenarios are focused on MPLS TE deployments, but may also apply
to GMPLS tunnels as well.
5. Section 3.1.1 :
OLD:
In the traffic
engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
information about network resources utilization is only available as
total reserved capacity by traffic class on a per interface basis;
individual LSP state is available only locally on each LER for it's
own LSPs. In most cases, this makes good sense, as distribution and
retention of total LSP state for all LERs within in the network would
be prohibitively costly.
NEW :
In the traffic
engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
information about network resources utilization is only available as
aggregated capacity by traffic class on a per interface basis;
individual LSP state may be available only locally on each LER/LSP
for it's
own LSPs. In most cases, this makes good sense, as distribution and
retention of total LSP state for all LERs/LSRs within in the network
would
be prohibitively costly.
6. Second paragraph : Another use case would be the GMPLS restoration.
7. Section 3.1.2. : MPLS TE control plane -> control plane, this is not
MPLS TE specific.
8. New section proposed 3.1.2.6. Pre-planned sharing :
Shared-mesh restoration defined in [RFC4872] is a restoration mechanism which
allow sharing of protection resource for risk-disjoint working path. The
sharing decision is a local decision as the head node does not know what are
the resources used for shared protection and which SRLGs are protected by them.
The local decision may be also influenced by the order of the TE-LSP setup. A
stateful PCE with this information in its LSP state database will be able to:
o Optimize the sharing of protection resources
o Allow LSP maintenance operation to have fewer impact on protection
resources
o Allow to reoptimze the protection resource
9. New section proposed 3.1.2.7. Discrete resource path constrained
allocation
Some networks are using discrete resources which are constrained by other
TE-LSPs or switching capabilities. Typical use case is limited label switching
capabilities (label stack-depth, HW constraints, physical constraint). Path
computation in such type of network require a more complete resource and TE-LSP
view in order to compute valid path. A stateful PCE can use the TE-LSP to
provide better optimization and reduce blocking. In addition IGP information
is not required to carry extended resource usage.
10. The document draft-zhang-pce-stateful-pce-app-02 has some other
generic, GMPLS and technology specific use cases, which could be added, I would
expect the authors of this draft to indicate this as comment to the WG draft,
11. Section 5.2 : PCRpt : It could be useful to use the PCEP response
attribute, in the LSP status report : the path with attribute-list is reported
(So when referring to RFC5440 section 6, this would cover the different
extensions). This would also apply to the PCUpd
12. Section 5.4 : which messages are allowed during State synchronization?
Is it allowed to have PCReq/Notify for instance?
13. Section 5.7 : too MPLS-TE specific, a GMPLS stateful PCE will not be
compliant. This should be in the protocol-specific part.
14. Section 5.6.2 : What happens if the update is not acceptable? A PCErr
may be returned. (In section 8.4 a new error similar to type 20 value 1 could
be used)
15. Section 5.6.2 : the statement "A PCC MUST NOT send to any PCE a Path
Computation Request for a delegated LSP." Is contradicting the PCC control,
the PCC may not fully delegate all aspects to the PCE, this seems too strong
for me.
16. Section 6.1. and Section 6.2 : path-list is confusing, you indicate
its technology-specific, however its defined in RFC5440 section 6.5, I would
suggest :
<state-report> ::= <LSP>[<path-report-list>] where <path- report
-list>::=<path-report>[<path-report-list>] and <path-report> ::=
<end-point-path-pair-list> or <path> [<technology-specific-path>
17. Section 6.2 : proposed additional text :
"If the PCUpd cannot be satisfied (PCC overload, unsupported object or TLV),
the PCC MUST respond with an PCErr message" .
This in combination with draft-ietf-pce-enhanced-errors would allow a proper
and generic handling. Some processing rules defined in other document in the
PCReq processing would also apply for the PCUpd. In addition new error code
should be allocated, if the LSP identifiers cannot be supported by the PCC,
this should turn into specific errors.
18. Section 7.1.1 : The delegation and state timeout are mentioned in the
document, it could be useful to also negotiate those (or others) as part of the
STATEFUL-PCE-CAPABILITY object :
a. DELEGATION-TIMEOUT : In this document only set by the PCC, could be
used by
b. RESTART-TIMEOUT : indication by the PCEP Peer for session reconnection
time (node restart time for instance), may be used by the Peer to adjust its
timeout.
19. Section 7.2.1 : CLI can be removed, it is not necessary. In addition
"If the operator does not specify an unique symbolic name for a path, the PCC
MUST auto-generate one" (change is "an unique"),
20. Section 7.2.1 : Why not add this TLV to the LSPA (and mandate LSPA), it
would fit better in LSPA
21. Section 7.2.2 : This support explicitly RSVP Class type 6, but you are
missing RSVP Ctype 3 and 4, In addition Class type 169 (USER_ERROR_SPEC, as
defined in RFC5284) is not supported. In addition I would like to suggest to
have on TLV type for ERROR spec (covering RSVP ERROR_SPEC and USER_ERROR_SPEC),
containing the RSVP objects
22. Section 9.1. : the statement "A PCC implementation which allows
concurrent connections to multiple PCEs SHOULD allow the operator to group the
PCEs by administrative domains" seems a more general requirement that could be
used in other cases. Is it meaningful to add this in the MIB document?
23. I think that draft-farrkingel-pce-abno-architecture-02 provides a good
model, and the stateful PCE models presented in this document should use the
architectural components and interfaces of the document. I found the section
1.1 particularly applicable.
Mit freundlichen Grüßen / Best Regards
Cyril Margaria
Nokia Siemens Networks Optical GmbH
St.Martin-Str. 76
D-81541 München
Germany
mailto:[email protected]
Phone: +49-89-5159-16934
Fax: +49-89-5159-44-16934
----------------------------------------------------------------
Nokia Siemens Networks Optical GmbH
Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 197143
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
