On 07/11/2011 17:47, Alia Atlas wrote:
We do have framework RFCs, but not requirements documents.
A question that we're actively looking for feedback on is whether the
WG wants to focus first on complete coverage solutions in the hope of
having a small set of solutions, on solutions that solve pieces of the
problem for some networks, or simply to evaluate solutions as they
come up.
While I have always been in favour of complete coverage solutions, I do
think that we need to consider the tradeoff between complexity (not just
computational complexity, but implementation, deployment and operational
complexity) and complete coverage. So I wouldn't like to exclude non
complete coverage solutions (and indeed to some extent all solutions
that cannot deal with arbitrary combinations of failures are in some
sense incomplete) from consideration, especially if they are "low cost"
compared to more complete solutions.
Since a part of this re-chartering is to clarify that the design focus
for hop-by-hop fast-reroute activity is in RTGWG, I agree that we
should explicitly call out LDP and multicast since the wording isn't
as assertive about that.
Yes, agreed.
Mike
Alia
2011/11/7 John G. Scudder<[email protected]>:
Some of this seems too detailed for a charter, and like it might go better in a
requirements document. (Did we do one of those, years ago? It might be worth
updating even so.)
--John
On Nov 3, 2011, at 7:56 AM, András Császár wrote:
Some further comments:
We probably shoud define "failure" a bit more clear. Single link, single node,
SRLG (local or remote), multiple failures.
And also we probably should discuss this part a bit: "A specific goal of
fast-reroute mechanisms is to provide up tocomplete coverage".
In my view, the target solution, while being practical, should be able to
provide
1. Complete coverage for all single link, single node and single SRLG (local
and remote) failures and for a reasonable number of pre-configured multiple
failure cases deemed important by the operator.
If we can't find such a practical solution then we can fall back to a solution,
which provides
2. Complete coverage for all single link, single node and single SRLG (local
and remote) failures.
If we can't find such a practical solution then we can fall back to a solution,
which provides
3. Complete coverage for all single link, single node and single local SRLG
failures.
If we can't find such a practical solution then we can fall back to a solution,
which provides
4. Complete coverage for all single link and single node failures.
Only if we can't find such a practical solution, should we fall back to a
solution, which provides
5. Coverage higher than LFA for many/most single link and single node failures.
András
From: [email protected] [mailto:[email protected]] On Behalf Of
András Császár
Sent: 2011. november 3. 11:56
To: Retana, Alvaro; [email protected]
Subject: RE: Charter Update (Discussion)
Hi!
I think the proposed charter text is OK.
Comments:
- I have the feeling that we should add LDP-MPLS explicitly. I know that implicitly we
mean IPFRR for IP and LDP, too. And I also see that we have the "enhancements to
hop-by-hop distributed routing related to fast-reroute" portion in the proposed
charter, which includes LDP. But still maybe saying LDP-MPLS explicitly would be good for
clarity.
- The same goes for multicast. I see the last milestone is for multicast,
that's OK, but maybe we should add it explicitly to the charter text.
- Another thought regarding LDP, again: Do we have a position on whether an
LDP-only FRR solution (i.e. which would not work for plain IP) but provides
100% coverage is of interest? Or do we want to have a solution that is
applicable to both plain IP and LDP-MPLS?
Maybe we should add something like this to the charter text: "...A specific goal of
fast-reroute mechanisms is to provide up to complete coverage when the potential failure
would not partition the network. The RTGWG seeks FRR solutions for both unicast and
multicast on pure IP and LDP/mLDP-MPLS networks."
- With some folks we were discussing in the background that the WG might profit
from an informational doc which lists/overviews and compares objectively all
the proposed solutions. There is a pletora of proposals out there, some might
have not even appeared at the IETF. Of course, we don't necessarily need to
state such a doc explicitly as a milestone, I don't know.
- If the multicast milestone is Apr 2012, then it should be earlier. Or if it
was meant for Apr 2013, then the year needs to be corrected.
Andras
From: [email protected] [mailto:[email protected]] On Behalf Of
Retana, Alvaro
Sent: 2011. november 3. 2:13
To: [email protected]
Subject: Charter Update (Discussion)
Hi!
We’re in the process of updating the WG charter and the list of milestones.
The main objective of the update is to clarify that FRR-related topics are
officially part of this WG – the main change is contained in the second
paragraph. Please take a look below and send your comments.
For reference, here’s the current charter:
http://tools.ietf.org/wg/rtgwg/charters
Thanks!
Alvaro.
The Routing area receives occasional proposals for the development and
publication of RFCs dealing with routing topics, but for which the
required work does not yet rise to the level where a new working group is
justified, yet the topic does not fit with an existing working group,
and it is either not ready for a BOF or a single BOF would not
provide the time to ensure a mature proposal. The RTGWG will serve as
the forum for developing these types of proposals.
The RTGWG also focuses on enhancements to hop-by-hop distributed routing
related to fast-reroute and loop-free convergence. A specific goal of
fast-reroute mechanisms is to provide up to complete coverage when the
potential failure would not partition the network. All work in this
area should be specifically evaluated by the WG in terms of practicality
and applicability to deployed networks.
The RTGWG mailing list will be used to discuss the proposals as they
arise. The working group will meet if there are one or more active
proposals that require discussion.
The working group milestones will be updated as needed to reflect the
proposals currently being worked on and the target dates for their
completion. New milestones will be first reviewed by the IESG. The
working group will be on-going as long as the ADs believe it serves a
useful purpose.
Apr 2012 Submit Composite-Link Requirements to IESG for publication as
Informational
Apr 2012 Submit Ordered FIB architecture to IESG for publication as
Informational
Nov 2012 Submit Composite-Link Framework to IESG for publication as
Informational
Apr 2013 Submit specification on Advanced IP Fast Reroute mechanism to IESG
for publication as Proposed Standard
Apr 2012 Submit initial Internet Draft on Multicast IP Fast Reroute Architecture
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
