[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG last calls - comments on crankback i-d
hi adrian,
some coments here below
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;
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 ?
3. section 3.
i may have missed it but the definition of "Explicit and Implicit
Re-routing Indications" is not provided
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 -
also by context you mean "position" of the element under failure wrt to
its sequence as part of the ERO ?
5. section 4.4
is it " error indication upstream" or indicationS (collection) ?
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
7. section 6.4
point 2 - why segment-based is referred to as "hierarchical" - do you
refer to an "horizontal hierarchy" here ?)
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."
not sure to understand the "ERO_NEXT_CONTEXT" TLV
" 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]."
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
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
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."
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
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
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"
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>
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"
4. section 5. - point 3)
instead of "... (particularly in the GMPLS context),"
i guess you mean for non-PSC LSP ?
5. section 7.2
"IF_ID PHOP" -> IF_ID RSVP_HOP ?
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 ?
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 ?
aslo do no provide the exact pointer for TE Router ID and Router ID in
the IS-IS context
hope this will help
---
Kireeti Kompella wrote:
Hi,
This is to initiate CCAMP WG last calls on:
draft-ietf-ccamp-crankback-04.txt
and
draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Please send your comments to the list (preferably) or to the authors
by April 14, 23:59 GMT (which is when the last calls end).
Thanks,
Kireeti.
-------
.