[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG last calls - comments on crankback i-d
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
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