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 protected]] 代表 [email protected]
[[email protected]]
发送时间: 2013年11月24日 4:00
收件人: [email protected]
主题: rtgwg Digest, Vol 107, Issue 21
Send rtgwg mailing list submissions to
[email protected]
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 protected]
You can reach the person managing the list at
[email protected]
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 protected])
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 protected]
To: [email protected]
Cc: [email protected]
Subject: I-D Action: draft-ietf-rtgwg-remote-lfa-04.txt
Message-ID: <[email protected]>
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 protected]>
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Fwd: New Version Notification for
draft-ietf-rtgwg-remote-lfa-04.txt
Message-ID: <[email protected]>
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 protected]>
To: Mike Shand <[email protected]>, Stefano Previdi
<[email protected]>, "So Ning" <[email protected]>, Ning
So <[email protected]>, Clarence Filsfils
<[email protected]>, Stewart Bryant <[email protected]>
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 protected]
https://www.ietf.org/mailman/listinfo/rtgwg
------------------------------
End of rtgwg Digest, Vol 107, Issue 21
**************************************
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
