Subject: comments//Re: I-D Action: draft-ietf-rtgwg-remote-lfa-04.txt

From: "Wunan (Eric)" <[email-masked]>
Date: Fri, 29 Nov 2013 06:40:16 +0000

Hi Stewart,

Some thoughts.

1. For the terminology part, as a reader, i think it will be more logical to go along with this order, just like section 4 did.
P-space, Extended P-space, Q-space, PQ node, Repair tunnel, Repair tunnel end then Remote LFA.
To understand the exact concept of Extended P-space, i have to understand P-space first which needed to jump into the section of 4.2.1. 
Maybe the terminology part can explain itself without referring formal section plus it don't have to explain everything since detail is in the following section.

2. Section 3: "This is equivalent to providing a virtual 
   loop-free alternate to supplement the physical loop-free alternates.
   Hence the name "Remote LFA FRR". "
I didn't get the "Hence", i think if "Hence" comes out, it should be "Virtual LFA FRR". 
Remote didn't come from virtual i think. Maybe this is not the place to explain the RLFA's origin.

3. Section 3.2: "The deployment in an MPLS/LDP environment is
   relatively simple in the data plane as an LDP LSP from S to the
   repair tunnel endpoint (the selected PQ node) is readily available,
   and hence does not require any new protocol extension or design
   change.  "
   
   Section 7: "To establish an targeted LDP session with a candidate remote LFA
   repair target node the repairing node (S) needs to know what IP
   address that the remote LFA repair target is willing to use for
   targeted LDP sessions.  Ideally this is provided by the remote LFA
   repair target advertising this address in the IGP in use.  Which
   address is used, how this is advertised in the IGP, and whether this
   is a special IP address or an IP address also used for some other
   purpose is out of scope for this document and must be specified in an
   IGP specific RFC."
   
TLDP session is per failed link in RLFA. So it should be established automatically without network operator's involvment.
As stated above, the ip address used to establish TLDP should have one way to advertisebe.
Especially in MT scenario, maybe i want to use different ip address for different MT.
These things should be specified by specific RFC.

4. Section 3.2: "Consequently, the repair tunnel used
   must be provisioned beforehand in anticipation of the failure.  Since
   the location of the repair tunnels is dynamically determined it is
   necessary to automatically establish the repair tunnels.  "

The repair tunnels are established beforehand. After the failure happended, network will converge again, 
but this old repair tunnel has done its work, so will it be broken down to reclaim resource and re-establish when recover convergence happened?

5. Section 4.3, I think some of these functions missed some parameters.

Should it be like this:

    Compute_Neighbor_SPFs(self, fail_intf) //self's neighobr is computing
    
    Compute_Extended_P_Space(self, fail_intf) //self is computing EP
    
    Compute_Q_Space(dest, fail_intf)    //dest is computing Q
    
    Intersect_Extended_P_and_Q_Space(self, dest, fail_intf) //PQ is per fail_intf
    
          Compute_Extended_P_Space(fail_intf)
          foreach node y in network
              y.in_extended_P_space = false
              // Extend P-space to the P-spaces of all reachable
              // neighbours
              foreach interface intf in self
                  if (intf.remote_node != fail_intf.remote_node)    /*In broadcast network, 
                                                                                         *if the link down it will affect all nodes on this link, 
                                                                                         *not only one remote_node. */
                      if ( D_opt(intf.remote_node, y) <
                           D_opt(intf.remote_node, self) +
                           D_opt(self,fail_intf.remote_node) +
                           D_opt(fail_intf.remote_node,y) )
                       y.in_extended_P_space = true    

Eric

________________________________________
发件人: rtgwg [[email-masked]] 代表 [email-masked] [[email-masked]]
发送时间: 2013年11月24日 4:00
收件人: [email-masked]
主题: rtgwg Digest, Vol 107, Issue 21

Send rtgwg mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/rtgwg
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rtgwg digest..."

Today's Topics:

   1. I-D Action: draft-ietf-rtgwg-remote-lfa-04.txt
      ([email-masked])
   2. Fwd: New Version Notification for
      draft-ietf-rtgwg-remote-lfa-04.txt (Stewart Bryant)

----------------------------------------------------------------------

Message: 1
Date: Fri, 22 Nov 2013 13:13:33 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-rtgwg-remote-lfa-04.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Remote LFA FRR
        Author(s)       : Stewart Bryant
                          Clarence Filsfils
                          Stefano Previdi
                          Mike Shand
                          Ning So
        Filename        : draft-ietf-rtgwg-remote-lfa-04.txt
        Pages           : 24
        Date            : 2013-11-22

Abstract:
   This draft describes an extension to the basic IP fast re-route
   mechanism described in RFC5286 that provides additional backup
   connectivity for link failures when none can be provided by the basic
   mechanisms.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-remote-lfa-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

------------------------------

Message: 2
Date: Fri, 22 Nov 2013 21:16:09 +0000
From: Stewart Bryant <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]"
        <[email-masked]>
Subject: Fwd: New Version Notification for
        draft-ietf-rtgwg-remote-lfa-04.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

 From my previous email, you will see that I did
everything that was minuted at the IETF meeting
except the extra sim, which I have not been provided
with.

As duty editor, I think that we are now ready
for WG Last Call on this draft.

- Stewart

-------- Original Message --------
Subject:        New Version Notification for draft-ietf-rtgwg-remote-lfa-04.txt
Date:   Fri, 22 Nov 2013 13:13:34 -0800
From:   <[email-masked]>
To:     Mike Shand <[email-masked]>, Stefano Previdi
<[email-masked]>, "So Ning" <[email-masked]>, Ning
So <[email-masked]>, Clarence Filsfils
<[email-masked]>, Stewart Bryant <[email-masked]>

A new version of I-D, draft-ietf-rtgwg-remote-lfa-04.txt
has been successfully submitted by Stewart Bryant and posted to the
IETF repository.

Filename:        draft-ietf-rtgwg-remote-lfa
Revision:        04
Title:           Remote LFA FRR
Creation date:   2013-11-22
Group:           rtgwg
Number of pages: 24
URL:             http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-remote-lfa-04.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa
Htmlized:        http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-remote-lfa-04

Abstract:
    This draft describes an extension to the basic IP fast re-route
    mechanism described in RFC5286 that provides additional backup
    connectivity for link failures when none can be provided by the basic
    mechanisms.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/rtgwg/attachments/20131122/6047d19b/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

------------------------------

End of rtgwg Digest, Vol 107, Issue 21
**************************************