Subject: relmote lfa draft edits

From: Stewart Bryant <[email-masked]>
Date: Fri, 22 Nov 2013 16:57:29 +0000

Here you go...

On 11/5/13 9:38 AM, "Stewart Bryant"<[email-masked]>  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