Hi Dimitri,
Thanks for the thorough review.
technical ---------
1. section 2.1
it seems from phrasing the term QoS is used in two different ways
"Using RSVP-TE, resources can also be reserved along a path to
guarantee or control QoS for traffic carried on the LSP" thus last
part of this sentence refers to the traffic oriented approach (as
detailed in RFC 2702) but after in this section (and in section
4.2) the term "QoS constraints" is used in a resource oriented
perspective;
Point taken. This needs to be clarified.
2. section 2.2
" The requirement for end-to-end allocation of lambda resources in
GMPLS networks without wavelength converters means that end-to-end
restoration is the only way to recover LSP failures. "
-> would it be possible to know how you came to this statement ?
Yes. Actually, it should read "may be the only way". Simply put,
segment protection may be much harder in networks of photonic
cross-connects because a particular lambda may already be in use on
other links. End-to-end protection offers the choice of use of
another lambda, but this choice is not available in segment
protection.
3. section 3.
I may have missed it but the definition of "Explicit and Implicit
Re-routing Indications" is not provided
The first paragraph was intended to convey this. We will clarify.
4. section 4.2.1
not sure to see why the "reason" of the failure is important beside
link, label, etc. (in particular since the persistence is limited
to the LSP under establishmnet) - but i guess it depends on the
semantic you put behind this word in the present context -
OK. It would probably help if we gave an example and a counter
example.
Off the top of my head: "temporary control plane congestion" has a
different impact on crankback rerouting to "cannot route to
destination".
also by context you mean "position" of the element under failure
wrt to its sequence as part of the ERO ?
Yeah. I don't think either of us has the right word here. We'll try
to find something that explains this a bit better.
5. section 4.4
is it " error indication upstream" or indicationS (collection) ?
Hmmm. One error indication (message) may report multiple errors. We
will clarify this by inserting the word "message".
6. section 5.2
"The Notify message may be used to expedite the propagation of
error notifications, but in a network that offers crankback routing
at multiple nodes there would need to be some agreement between
LSRs as to whether PathErr or Notify provides the stimulus for
crankback operation. "
this agreement is constrained by the re-routing behavior selection
(as listed in section 6.4
Yes. That would be a helpful cross-reference.
7. section 6.4
point 2 - why segment-based is referred to as "hierarchical" - do
you refer to an "horizontal hierarchy" here ?)
Probably best if we remove this word because it has overloaded
semantics with respect to hierarchical LSPs. What we meant is simply
that segment based protection allows you to protect ever smaller
segments in a nested way. For example...
A--B--C--D--E--F--G--H
| | | | | |
| | P--Q | |
| R----S---T |
W----X----Y----Z
8. section 7.2
not sure to understand the "Proposed ERO" TLV ? would it be
possible to describe this more than "MAY supply suggestions about
the ERO that could have been used to avoid the error."
Intention is to allow a downstream LSR to report that "I cannot route
using the supplied ERO, but if you had supplied *this* ERO it would have
been possible."
not sure to understand the "ERO_NEXT_CONTEXT" TLV
Both of these TLVs are described a bit further in 7.3.4. However, on
re-reading I see that there isn't enough information. The distinction
between TLVs 12 and 13 is the distinction between "this is the hop I was
trying to satisfy when I failed" and "this is the next hop I was trying
to reach when I failed".
" Link Identifiers:
A sequence of TLVs as defined here of type 3 that indicate incoming
interfaces at downstream nodes that have already participated in
crankback attempts and have been declared unusable for the current
LSP setup attempt."
-> definition does not match the one proposed above in the text
" For types 1, 2 and 3 the format of the Value field is already
defined in [RFC3471]."
Not sure what you are saying. Are you simply suggesting that the
defintion of the Value for type 27 should point to 3471?
9. section 7.4.1
" As described in section 3, a node receiving crankback information
in a PathErr must first check to see whether it is allowed to
perform re-routing. This is indicated by the Re-routing Flags in
the SESSION_ATTRIBUTE object during LSP setup request."
-> why do you make use of the session attribute since section 6.4
mentions usage of lsp attribute object
Good catch! Old text that should be replaced with LSP ATTRIBUTE.
10. section 7.3
in section 7.3.1 it is mentioned
" If crankback is not being used but an IF-ID ERROR_SPEC object is
included in a PathErr, ResvErr or Notify message, the sender SHOULD
include one of the TLVs of type 1 through 3 as described in
[RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in
[BUNDLE] and component links should be identified using the
principles described in that document.
A sender MAY include additional TLVs from the range 6 through 27 to
report crankback information, although this information will at
most only be used for logging."
[...]
"An LSR that proposes to perform crankback re-routing SHOULD
support receipt and processing of all of the fundamental crankback
TLVs, and is RECOMMENDED to support the receipt and processing of
the additional crankback TLVs."
in section 7.3.2 it is mentioned
" Error Report TLVs are those in the range 1 through 3. (Note that
the obsoleted TLVs 4 and 5 may be considered in this category, but
SHOULD NOT be used.)
As stated above, when crankback information is reported, the IF_ID
ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is
used, at least one of the TLVs in the range 1 through 3 MUST be
present. The choice of which TLV to use will be dependent on the
circumstance of the error and device capabilities. For example, a
device that does not support IPv6 will not need the ability to
create a TLV of type 2. Note, however, that such a device MUST
still be prepared to receive and process all error report TLVs."
in section 7.3.4 it is mentioned
" It is left as an implementation detail precisely when to include
each of the TLVs according to the capabilities of the system
reporting the error."
=> would it be possible to harmonize these MUST, SHOULD, MAY, etc;
? one way to achieve this is by reducing repetitions and probably
have 2 sub-sections instead of 4
Yes.
same comment in section 7.4.5 where it is mentioned
"When the node gives up it must propagate the failure message
further upstream and include crankback information when it does
so."
Same answer.
11. section 8.
" For example, when an intermediate LSR issues a PathErr message,
the signaling module of the intermediate LSR should interact with
the routing logic to determine the routing-protocol-specific link
or node ID where the blockage or fault occurred and carry this
information onto the Link TLV and Node TLV inside the IF_ID
ERROR_SPEC object."
-> Link TLV is not defined as part of the table ? would it be
possible to list to which TLV you are referring to
Yes. Means TLV 1, 2 or 3.
12. section 9.1
" In a network segmented into areas, the following procedures can
be used. As explained in Section 8.2, the LSP restoration behavior
is indicated in the Flags field of the SESSION_ATTRIBUTE object of
the Path message. If the Flags indicate "End-to-end re-routing",
the PathErr message is returned all the way back to the ingress
LSR, which may then issue a new Path message along another path,
which is the same procedure as in the flat network case above."
-> why do you make use of the session attribute since section 6.4
mentions usage of lsp attribute object
Ditto, above.
editorial ---------
1. title
"Crankback Signaling Extensions for MPLS and GMPLS Signaling"
is probably redundant i would suggest (but leave this at your
discretion)
"Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE"
OK
2. section 2.2
alignment with P&R terminology and concepts would be advisable
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt>
OK. Anything specific or do we just need to do a general parse?
3. section 4.2
"On the other hand, in a network partitioned into areas such as
with hierarchical OSPF,..."
why "hierarchical OSPF" and not simply "OSPF"
Because we like adding the word "hierarchical" at every oportunity
:-)
4. section 5. - point 3)
instead of "... (particularly in the GMPLS context),"
I guess you mean for non-PSC LSP ?
You guess correctly. Will tidy this.
5. section 7.2
"IF_ID PHOP" -> IF_ID RSVP_HOP ?
Yes.
6. section 7.2
" Node Identifiers:
A sequence of TLVs as defined here of types 1, 2 or 8 that
indicates downstream nodes that have already participated in
crankback attempts and have been declared unusable for the current
LSP setup attempt."
type 1, 2 does not define nodes in the proposed table ?
Not sure about this. Your point is valid, but it is also the case
that one may identify a node by one of its interfaces. Thus it may be
convenient to simply put the list of failed interfaces into this TLV and
thus identify the list of nodes that have failed to perform crankback.
I guess we need a little input from the implementers on this point.
7. section 8
" The ingress LSR, upon receiving the error message, should
interact with the routing logic to compute an alternate path by
pruning the specified link ID or node ID in the routing database."
i guess "node ID" refers to Router ID ?
Well, "TE Router ID". And, of course, "Routing database" should read
"Traffic Engineering Database".
also do no provide the exact pointer for TE Router ID and Router ID
in the IS-IS context
Yup. I think by using TE Router ID we are covered in the IS-IS case,
and we just need to update the text to identify the exact field.
hope this will help
It does, a lot.
Thanks, Adrian