Subject: Comment and suggestion for draft-iwata-mpls-crankback-01.txt

From: Edward Harrison <[email-masked]>
Date: Wed, 24 Oct 2001 14:54:17 +0100

Hi,

I've been looking at the Crankback draft (draft-iwata-mpls-crankback-01.txt)
and have a couple of questions/suggestions.  I have primarily been looking
at the draft from an RSVP perspective, so please forgive any RSVP bias in
what follows!

Reporting upstream Link blockages
=================================

In section 5, Location Identifiers of Blocked Links or Nodes, there is the
following sentence:

"Upon a link blockage, the first and second ER-Hop TLVs are
 returned, which means that the blockage location is the link between
 the two nodes indicated by these TLVs."

Whilst this seems to work fine if the blockage is on the downstream link,
there are circumstances where the blockage may be on the upstream link.  For
example, in RSVP when processing a Resv, there may not be sufficient
resources on the upstream link.  Alternatively, if out of band signalling is
used, the signaling message (e.g. an RSVP Path) may arrive at the downstream
node, but the data link to the upstream node may be unavailable.

In this scenario, using the first and second ER-Hop TLVs will indicate the
incorrect link (as they will indicate the downstream one).  I think the
downstream node should instead generate a TLV to identify the upstream end
of the link, returning this along with the first ER-HOP TLV.  Perhaps the
following text (or similar) could be used to clarify this:

"In some circumstances a node may wish to report a link blockage between
itself and the upstream node, in which case the first and second ER-Hop TLVs
should not be used (as these identify the downstream link).  This may occur
because the downstream node has no resources available on that link, or
because the data link is down, but the signaling message has arrived out of
band.  In these cases, the downstream node can use the Label Request's
source IP address (LDP) or PHOP object (RSVP) to generate an ER-TLV for the
upstream node.  It can use this generated ER-Hop TLV with the first ER-Hop
TLV to identify the link."

Dealing with ResvErr message using SE style
===========================================

In section 9.6, ResvErr usage, there is the following text:

"When a ResvErr carrying a Rerouting object is received at an egress
 LSR, the egress LSR MAY ignore this object and perform the same
 actions as for any other ResvErr. However, if the egress LSR supports
 the crankback extensions defined in this draft, it SHOULD generate a
 PathErr message and send it to the ingress LSR."

I think this fails to address ResvErr messages that use the Shared Explicit
(SE) style and actually refers to more than one LSP (for example, if make
before break is being used).  Under these circumstances multiple PathErr
message should presumably be sent, each containing the rerouting object.

Perhaps adding the following text would be appropriate:

"If the ResvErr uses the SE style and refers to more than one Path, a
PathErr SHOULD  be sent for each of the LSPs indicated in the Filterspec
object of the ResvErr."

Reporting Label information
===========================

I realise that your original draft concentrates on base MPLS rather than
GMPLS.  However, I can see situations where the Crankback information could
be enhanced in a GMPLS environment.  I don't know whether it is appropriate
to introduce specific GMPLS concepts into the draft, or whether one would
need a separate CCMAP version.  In either case I'll give you the immediate
example that sprang to mind so that you can think about whether it is
generally useful!

When Explicit Label control is used, it could be useful for the rerouting
information to contain not only information on the node or link that caused
the failure, but also, if it was a specific label operation that caused the
failure, information on the label that failed.

I'd like to propose adding a new rerouting subobect to provide information
where the label was the cause of a failure.  Here is a suggested definition
for the RSVP version of the object (if you agree that this is a useful new
object then I can provide an LDP definition as well).

Label-Rerouting Subobject

     The Label Rerouting subobject is used in conjunction with
     Explicit Label Control [GMPLS].  It is used to identify an 
     explicit label which was the cause of a setup blockage.

     It is intended to follow a node or link ID where setup blockage
     occurred, and indicates that the problem was caused for one of
     the following reasons :

      - Either of the upstream or downstream explicit labels in
        the first ERO hop on the Path Message are unacceptable.
      - A label set on the Path Message was unacceptable.  When
        using explicit label control, this will be a singleton
        label set.  It will have been constructed from the
        explicit label for the forward directional LSP at the
        upstream node.
      - An upstream label object on the Path message was 
        unacceptable.  When using explicit label control, this
        will have been constructed from the explicit label for
        the reverse directional LSP at the upstream node.
      - A Node was unable to switch between the input and output
        labels (either for the forward or reverse directional LSP).
        This is particularly relevant in optical networks.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Length    |  Error Code   |      Num      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Label ERO Subobject 1 (optional)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Label ERO Subobject 2 (optional)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
     The Type indicates the type of contents of the subobject.
     3   Label-Rerouting subobject

   Length
     The length in bytes of the subobject.

   Error Code
     The Error code should be set to one of the following values :

        0  -  The specified Label value(s) were unacceptable.
        1  -  The node was unable to switch between the input and output
              labels.

   Num
     The number of labels contained within this subobject. 

     In normal circumstances, this will be one.  However, there are
     conditions in which a node may wish to include two labels :
 
       - Both the labels for the forward directional and reverse
         directional LSP on a link were unacceptable.  
       - The node is unable to switch between input and output labels,
         and wishes to indicate the exact label values involved.
     
Note that this object may prove superfluous given the recent addition of
Acceptable Label Set to the GMPLS drafts.  That said, the two objects
provide subtly different things - Acceptable Label Set telling you which
labels you can use, whilst the above object tells you which ones you can't.
I'd be interested to know if you feel it would be useful to have these two
pieces of information, or whether Acceptable Label Set is enough.

Please let me know if you have any comments or would like to discuss any of
the above.

Regards,

Ed

-----------
Ed Harrison  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd.
http://www.dataconnection.com/
Tel: +44 20 8366 1177  Fax: +44 20 8363 1468