The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

Hi Ed,

Apologies for a very late reply, and thank you for your interest in this draft.

Comments in-line in your edited text.

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

As you note later, this (RSVP-only) scenario is covered in section 9.6.

Your point has a more general message, however, and the situation may
arise on the forward path (the downstream node is unable to reserve the
resources for the incoming link).

We will generalize the text to indicate that
- the use of ER hops as discussed is just an example
- the point is to provide (in forward path order) the two hops that
  encompass the link.

We will also beef up section 9.6 to be more explicit about where the
implementation should go for information to fill into the Rerouting
object.

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

Correct.  We will add something of this nature.

> Reporting Label information
> ===========================
>
> I realise that your original draft concentrates on base MPLS rather than
> GMPLS.

That's true, but at this time we don't see any need for an additional object
(although
we're happy to continue to look at this).

[SNIP]
> 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.

For example, if the lambda was specified in the ERO then identifying the link
that failed
together with a reason code is enough to identify the failed lambda.  There are
already reason codes (e.g. in generalized-rsvp-te) to cover these events.

If the lambda was not specified in the ERO then identifying which one failed may
not
be much use to the repair point.  But (as you say) the Acceptable Label Set
gives
lots of useful information about how tro modify the ERO to give it a good chance
of success.

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

Actually, knowing one label that you can't use, doesn't seem very helpful.
Knowing the full list that you can use seems more useful.

Again, there is a wider point which you raise which is useful.  We will look
more widely at providing supplementary information for resource failures.

Regards,
Adrian