The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Suggested improvements to the Path-Specific merge rules in dr aft- ietf-mpls-rsvp-lsp-fastreroute-03
What do you guys think of the following text from Nic? I made a small adjustment
to part of the sentence (marked by ^^^), but didn't change anything else.
I think the merging rules are identical in semantics to what I last proposed, even
though the number of rules further reduce by 1.
It is possible to see detours conflict with each other that MP cannot find
a final Path message that satisfy all of them. In that case, the additional
text in rule 3 is necessary, as well as the last paragraph.
In the last paragraph, is it better to send patherr messages and fail the
merging, or simply pick one of the detours and continue the merge? If we
pick continue, some of the detours will provide link protections but
not node protection. Is that acceptable?
Thanks to Nic for pointing out the potential merging problem.
Der-Hwa
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
(a protected LSP is one originated from this node, or with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the FAST_REROUTE object, or without the DETOUR object),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
one of these must become the chosen Path message. There could
^^^^^^^^^^^
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.
|
|