The MPLS WG Archive

[Nic Neate <nhn@dataconnection.com>]

Ping and Der-Hwa,

Thanks for your responses.  You've raised the following points which I'll
give you my input on below.
 - Der-Hwa's suggested merge rules.
 - Concern over interop with existing implementations.
 - Doubt whether failing to merge is possible.
 - Possibility of merging multiple protected Paths during LSP rerouting.


A.  Der-Hwa's suggested merge rules.

My understanding of the draft is that every Path we are merging is either a
protected Path (has a FAST_REROUTE object, or the "Local protection desired"
bit set in SESSION_ATTRIBUTE object) or a detour Path (has a DETOUR object).
This is stated by paragraph 3 of section 7.1.2 (although note that this
misses out the "Local protection desired" flag option):

   For all Path messages that do not have either a FAST_REROUTE or a
   DETOUR object, or the MP is the egress of the LSP, no merging is
   required.  The messages are processed according to [RSVP-TE].

Because that statement is there up front, I think we should just to refer to
"protected Paths" and "detour Paths" in the merge rules.  I've suggested
some new text at the bottom.


B.  Will there be interop problems with existing implementations?

I don't think so.  The Path message forwarded by the new merge rules may
have a different ERO, or be a protected Path instead of a detour.  That will
not matter to the downstream LSR though - it can process it in just the same
way as before.  Existing implementations will only need to be changed if
they wish to avoid the risk of forwarding a detour Path in preference to a
protected one.


C.  Is it possible that no received Path message is suitable for forwarding?

Only in very strained network topologies (but we do have it in system
test!).  Merging can fail either because each detour traverses a node that
another wants to avoid, or because the protected LSP traverses a node that
some detours want to avoid.  I think that these possibilities should be
covered by the draft.


D.  During LSP rerouting, we may need to merge multiple protected Paths.

I agree that this is a possibility.  It's covered by my new suggested text
below.


Taking all that into account, here's my suggested text for the merge rules.

   For all the Path messages that share the same outgoing interface and
   next-hop LSR, the MP runs the following procedure to identify a Path
   message to forward downstream.

     1. If one or more of the Path messages is for the protected LSP,
        one of these must become the chosen Path message.  There should
        only be more than one in the case that the protected LSP is
        being rerouted.  In that case it is a local decision to choose 
        which one to forward.  Quit.

     2. From the remaining set of detour Path messages, eliminate from
        consideration those that traverse nodes that others want to
        avoid.

     3. If several still remain, it is a local decision to choose which
        one to forward.  If none remain, then the MP may try and find a
        new route that does avoid all nodes that all merging detour
        Paths want to avoid and forward a Path message with that ERO.

   Once the final Path message has been identified, the MP MUST start to
   refresh it downstream periodically.  Other LSPs are considered merged
   at this node.  For bandwidth reservation on the outgoing link, any
   merging should be considered to have occured before bandwidth is
   reserved.  Thus, even though Fixed Filter is specified, multiple
   detours and/or their protected LSP which are to be merged due to
   sharing an outgoing interface and next-hop LSR will reserve only
   the bandwidth of the final Path message on that outgoing
   interface.

   If no merged Path message can be constructed then the MP SHOULD send
   a PathErr in response to the most recently received detour Path
   message.  If a protected Path is chosen to be forwarded, but it
   traverses nodes that some detours want to avoid, PathErrs should be
   sent in response to those detour Paths which cannot merge.

Thanks,

Nic