Dear Authors,
I have given some comments to you only, on the earlier version of this draft
few months back and I see some of them are taken care. Thx.
After re-reading this version, I felt this is indeed addressing the important
aspect and the value of policy based selection of alternatives
As opposed to the alternatives with best protection. This document brings out
lot of use cases and the configuration knobs to
achieve the goal of the "policy" based preference on possible LFAs.
However, I see some of the sections documented are not directly related to the
uses cases presented in Section 2, which in principle
shows how and why the best protection is not good (excluding the IS-IS overload
case) in all cases.
For example:
1. Section 3.1, which suggests the activation granularity requirement of the
LFAs from Context, instance to address-family and per-prefix.
Here some of the choices are natural but I don't think this addresses any
of the problems documented in Section 2.
"..This means that if a specific
prefix must be protected due to a configuration request, LFA must
be computed and installed for this prefix even if the primary
outgoing interface is not configured for protection."
Could you clarify the must (2) in the sentence? Do you intend to say
"MUST" there?
Also I feel, for example, having per-prefix granularity for provisioning
LFA or not is an implementation choice than an interoperability
issue while deployment.
2. Section 4.3, "Required local information" Says -
"MUST provide coverage information per activation domain of LFA
(area, level, topology, instance, virtual router, address family
...)."
To me this is good to have information and be very helpful for the
operator but I am not sure mandating the coverage information granularity
is addressing any of the issues presented in Section 2.
3. Similarly Section 4.4 coverage monitoring guidelines for the vendor
implementations are good ones but these are neither addressing any issues
presented in Section 2 nor helping solve any interoperability issue.
The problem I see with this is lot of implementations may quickly become
non-compliant from customers point of view once this becomes RFC. Do you see
that way?
Specific review Comments:
=====================
1. Section 2.1
When the core link R8-R7 fails, R8 switches all traffic destined to
all the PEx towards the edge node PE2.
What is "all the PEx"??
2. Section 2.2
"In the figure 2, let us consider the traffic coming from PE1 to PEx.
Nominal path is R9-R8-R7-R6-PEx."
You might mean to say R9-R8-R7-R10-R6-PEx ? Can you clarify?
3. Section 2.3
Though it's not important to illustrate your point of using sub-optimal core
links as LFA, it's good to mention the link costs of R3-PE1 and PE1-R4.
Otherwise PE1 could become another potential node protecting alternative via
non-core or whatever.. (at least can avoid confusion for the reader).
4. For IGPs what exactly you meant when you say "topology" and how this is
different than first bullet "Per address-family"?
5. Section 3.2.1
"Especially, computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD to be
performed before best alternate selection."
SHOULD to be ==> SHOULD be
Also, say you might have a legacy node to deal with and you are not able to
establish TLDP with PQ here
in that case, you might look for a knob to choose the policy (remote or
local policy).
6. "3.2.5. Details on criterions"
Didn't understand the title and all sub-sections listed under should
instead be 3.2.x level? I am saying this because I lost
where I was while reading. I would suggest to re-organize better.
7. 3.2.5.1. LFA and ECMP
It should have been "ECMP LFAs"
And..
"As mentioned in [RFC5286] Section 3.4., protecting a link within an
ECMP by another primary nexthop is not a MUST. Moreover, we already
presented in this document, that maximizing the coverage of the
failure case may not be the right approach and policy based choice of
alternate may be preferred."
If you just want to prevent one of the other ECMP link as LFA then you can
provision "local" SRLGs.
Then in this case you might get L3 or L4 but you are seeking both as LFAs.
I see the current text put
Lot of emphasis on the point of not using one of the primary ECMP paths as
alternatives with citation
on RFC 5286.
However, you are *also* seeking for an ECMP LFA (if available, instead of
tie breaking and give one
LFA eventually from the non-bundle).
Also I didn't fully understand how can one enforce this as one can have
another equal cost
alternate (non-bundled) path from PE1 to PE2 via P2 or some Px node. It
seems in this case you are
looking for all non-ECMP LFAs to be installed as alternatives?
8. Section 3.2.5.5
"Rather than tagging interface on each node (using link color) to
identify neighbor node type (as example), it would be helpful if
routers could be identified in the IGP. "
a) After this it completely talks IS-IS language. Probably this should be
revisited to make it generic or applicable to the other IGP.
b) Coming to IS-IS, you referred I-D.psarkar-isis-node-admin-tag but the
text suggests, its own algorithm to identify the neighbor with
TLV135 and is not complete in many fronts.
I would suggest revisit this section completely to focus on the point your of
"neighbor preference" rather than incomplete IGP details.
9. Section 4.5
"4.5. Deterministic and documents LFA selection behavior"
The title didn't sound correct.
--
Uma C.
-----Original Message-----
From: rtgwg [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, January 22, 2014 5:02 AM
To: [email protected]
Cc: [email protected]
Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt
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 : Operational management of Loop Free Alternates
Authors : Stephane Litkowski
Bruno Decraene
Clarence Filsfils
Kamran Raza
Martin Horneffer
Pushpasis Sarkar
Filename : draft-ietf-rtgwg-lfa-manageability-01.txt
Pages : 21
Date : 2014-01-22
Abstract:
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic
(and MPLS LDP traffic by extension). Following first deployment
experiences, this document provides operational feedback on LFA,
highlights some limitations, and proposes a set of refinements to
address those limitations. It also proposes required management
specifications.
This proposal is also applicable to remote LFA solution.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-01
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/
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
