WG last calls - cranback ID

[Arthi Ayyangar <arthi@juniper.net>]

Hi Adrian,

Here are some comments (marked <AA>) on the crankback ID.

thanks,
-arthi

---------
1.1 typo : documentaiton

2.2
Crankback routing schemes could be used to notify the upstream LSRs
of the location of the failure.

<AA> Do you mean "Cranback signaling schemes could be used to notify" ?
                           ----------
     I observed that in some places crankback signaling and cranback routing
     are used interchangeably. Need to clarify ?

4.2.2
   If the crankback information can be used to compute a new route
   avoiding the blocking problem, the route can be signaled as an
   Explicit Route.

<AA> How about "If the crankback information can be used to compute a new
   path avoiding the blocking problem, the path can be signaled with a new
   Explicit Route."


7.2
<AA> What is the PROPOSED_ERO for ? Why can't the node doing crankback
re-routing simply figure out the new path based on constraints and
failures history in the downsstream network that he probably understands
best ? Why do we want the node reporting error to suggest an ERO ?
Same question about 26 and 27 as well. It would be intuitive if the node
reporting failures simply reports the failure and leaves the guesswork and
computation to the node taking the re-routing action. That way the
reponsibility of each node is well-defined. Also, it is the node doing
the re-route that has the bigger picture in the end.


7.3.1
<AA> I am not too sure of the following statement:-

  "If crankback is being used, the sender of a PathErr, ResvErr or
   Notify message MUST use the IF_ID ERROR_SPEC object and MUST include
   at least one of the TLVs in the range 1 through 3 as described in
   [RFC3473], [BUNDLE], and previous paragraph."

The assumption here is that IF_ID ERROR_SPEC is always being used.
In section 5.1 we acknowledge that with RSVP-TE crankback re-routing can
be performed explicitly avoiding the node or interface reported in
ERROR_SPEC; i.e. no TLVs. So, the above sentence is only true in the
context of GMPLS RSVP-TE. You may want to clarify this once somewhere.


7.3.3

   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.

<AA> Why is the requirement for 'crankback re-routing' different from
     that for 'crankback' in section 7.2 ? Why isn't it enough for
     the LSR to support just the Error Report TLVs (1-3) in order to
     perform cranback re-routing ?

<AA> What information does DOWNSTREAM_LABEL and UPSTREAM LABEL provide to
     some node several hops upstream ? How is the node doing cranback
     re-routing going to use this info and enforce it along the new path?

7.4.4 When Re-routing Fails

   However, when a node was responsible for expanding or replacing the
   explicit route as the LSP setup was processed it MUST update the
   crankback information with regard to the explicit route that it
   received. Only if this is done will the upstream nodes stand a
   chance of successfully routing around the problem.

<AA> When you say "update", is the LSR replacing old crankback info with
new crankback info that it generates or is it appending this to received
crankback info in PathErr ? Also, is this a new PathErr (with a new src
addr) or the same PathErr that was received ? The reason I bring this up is
because elsewhere in the doc, you talk about intercepting and terminating
the error. I think you should clarify this in this section.

7.5. Notification of Errors

<AA> Is this section missing PathErr because it has been discussed in the
rest of the document ?

--------



> 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.
> -------
>