Here you go...
On 11/5/13 9:38 AM, "Stewart Bryant"<[email protected]> wrote:
Hi Acee
Any chance of a copy of your mins - no matter how rough - so I
can start on my doc actions.
Stewart
Remote LFA - Stewart Bryant (See slides)
- See changes to current version in slides.
- Steward does not want to merge with the node repair
document. There was consensus in the room
to move on w/o merging.
N/A to this revision
- Extended P-space vs P space explained. Consesus is the
example algorithm should include both the P-space
and Extended P-space.
Alia: Believes there is still confusion on P-space vs
Extended P-space.
Chris Bowers: Confusion with all the spaces in the
document. Can it be simplifies?
Stewart: Can move Extend P-space ahead of Q space in
description.
Please look at the new section 4.2.1
To compute the repair path for link S-E we need to determine the set of routers
which can be reached from S without traversing S-E, and match this with the set
of routers from which the node E can be reached, by normal forwarding, without
traversing the link S-E.
We will proceed as follows: we will describe how to compute the set of routers
which can be reached from S without traversing S-E. We call this the S's
P-space with respect to the failure of link S-E. We will then note that S is
able to use P-Space of its neighbours since S can determine which neighbour it
will use as the next hop for the repair. We call this the S's Extended P-Space
with respect to the failure of link S-E. The use of extended P-Space allows
greater repair coverage and is the preferred approach. Finally we will show how
to compute the set of routers from which the node E can be reached, by normal
forwarding, without traversing the link S-E. This is called the Q-space of E
with respect to the link S-E. The selection of the prefered node from the set
of nodes that an in both Extended P-Space and Q-Space is described in [4.2.2]
A suitable cost based algorithm to compute the set of nodes common to both
extended P-space and Q-space is provide in [4.3]
Then theer is 4.2.1.1 P-Space, 4.2.1.2 Extended P-space and 4.2.1.3 Q-space
- Cost Based Algorithm - Style question.
Uma Chunduri - Why is algorithm not in appendix.
Stewart - Graph vs Cost Reachability - both algorithms
put into the main body.
Uma - Perfers appendix.
I think the WG consensus has been to put it in the body.
I will move it if the chairs tell me the consensus is otherwise.
Chris - The text says it is just an example.
Uma - The downstream check is in the algorithm but not
the text.
Stewart - It was in the algorithm provided by Chris.
Alia - RFC 5286 indicates that downstream checking can
be avoid loops.
Added to the end of Section 4.2.2
As described in [RFC5286], always selecting a PQ node that is downstream with
respect to the repairing node, prevents the formation of loops when the failure
is worse than expected. The use of downstream nodes reduces the repair
coverage, and operators are advised to determine whether adequate coverage is
acheived before enabling this selection feature.
I also added a list of definitions of terms used in the algorithm text
- LFA with RLFA versus only R-LFA
Chris: The section with the alternate view creates
confusion.
Email from Chris: Following up on an item discussed in
the meeting. We agreed that the paragraph in section 4.2.2
that describes extended P-space in terms of (local)LFA
should be removed because this alternative description
may confuse the reader more than it enlightens
Removed the text
Stewart: Wants LFA to be the primary with RLFA added.
Acee: LFA has advantage of providing Extended P-Space
and working w/o tunneling.
Hannes: Agrees and clarifies Stephane's comments.
Uma: Agree with making LFA primary calculation.
Stewart: Will add text on policy engine to decide on
LFA and RFLA calculation applicability.
Stewart: Points out that you can calculate both LFA
and RLFA.
I have added to 4.2.2
It is a local matter whether the repair path selection policy used by the
router favours LFA repairs over RLFA repairs. An LFA repair has the advantage
of not requiring the use of tunnel, however network manageability
considerations may lead to a repair strategy that uses a remote LFA more
frequently [I-D.ietf-rtgwg-lfa-manageability]
- Targeted LDP Address
- Advertise in protocol. This is preferred. However,
some boxes don't advertise.
- Management configuration as a requirement.
- Pick an address arbitrarily.
Uma: What configuration is expected?
Stewart: Could be silent since it is a vendor
implementation issue.
Hannes: Lowest IP address is useless. A node should
be able to advertise that it doesn't support
T-LDP.
Rob Shakir - Draft should not remain silent on this
issue.
Stewart: Use Router-ID if not configured to do otherwise
like using a different address.
The text now says:
In the absence of a protocol to learn the preferred IP address for targeted
LDP, an LSR should attempt a targeted LDP session with the Router ID [RFC2328]
[RFC5305] [RFC5340], unless it is configured otherwise.
Uma: Do coverage numbers in include downstream
protection?
Stewart: No - will include numbers if they can be
readily obtained.
I do not have these numbers
- Figure 1 changed or not?
Stewart: Will not be changed.
- Final Comments?
Figure left alone
Hannes: I don't understand relucance to merge with node
protection.
Stewart: Does not want to merge. Wants to finish draft. Node
protection problem can quickly get out of control.
Hannes: This would be valuable implementation experience.
Alvaro: Already have "rough" consensus on moving forward
with the draft.
When the online XML2RFC compiler comes back online I will compile and upload.
Stewart
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
