On 10/9/13 5:06 PM, "Alia Atlas" <[email protected]<mailto:[email protected]>>
wrote:
<WG Chair Hat Off>
Alia:
Hi!
I pruned most of the text off to leave the relevant parts.
Thanks!!
Alvaro.
. . .
The draft has an intended status of Informational. However, the Introduction
reads: "This document defines the MRT Lowpoint algorithm to be used as a
standard in the default MRT profile for MRT-FRR." Which one is it?
[Alia] I think that the algorithm draft needs to be standards track. I
apologize for not updating the intended status - I was focused on the contents.
IMHO, there's a significant difference in saying "this is an algorithm than can
be used" (informational) vs "this is the algorithm that MUST be used"
(standard). For the record, I have no issues with adopting this draft with an
intended status of Informational.
[Alia] The intent is to have signaling that says this is the algorithm being
used. There's capabilities to indicate different algorithms - but I do think
that this particular algorithm and details must be standards-track for
interoperability.
The capabilities you're talking about are in I-D.atlas-ospf-mrt, right?
What I see in there is a way to indicate which profile is supported..which I
guess ties into the algorithm (for example, the Lowpoint is tied in the draft
to the default profile).. It's not a direct way of indicating the algorithm,
but that's what you mean, right?
BTW, I have no problem in the indication being indirect..
BTW2, on the architecture draft (Section 7) the default profile is
described..but it took me a while to find it because the words "default MRT
profile" showed up 2-3 paragraphs before the profile was actually defined. It
might be nice (for people like me) to clearly state: "This is the default MRT
profile:".
I should read the architecture draft closer..but isn't it like putting the
carriage before the horse to specify there (and not in the algorithm draft)
that the Lowpoint algorithm is the one used in the default MRT profile?
. . .
1. I found it interesting that, even though the document is defining an
algorithm that when implemented will need to have consistency across nodes,
there was no reference to RFC2119 — but some of the words were capitalized
anyway. Even then, only 4 "MUST" and 1 "SHOULD" appeared. I realize that the
count of MUST/SHOULD is no indication of anything, but it doesn't feel right
for a 40+ page document. I would appreciate if the authors would not just add
the 2119 reference (nit), but if they would also comb the text for parts where
a little more normative direction might help (which doesn't necessarily
translate into MUSTs).
[Alia] Agreed - in general, what I intend to do is to have the explanatory text
that explains the logic of the algorithm and how it works much as it is - and
then to pull together the different parts of the pseudo-code into a fully
detailed algorithm (some by reference to the earlier parts) that indicates the
MUST/SHOULD aspects. The specific request though seems more to be to take a
careful read through and clarify what is MUST and what is SHOULD.
I think the end result should be the same. All I want it to make sure that the
mandatory parts are clear for everyone to implement.
. . .
1.
* Root Selection. No algorithm is provided. There's a reference to
I-D.atlas-ospf-mrt, where a suggestion is made ("..the router with the highest
GADAG Root Selection Priority is picked to be the GADAG Root"). IMHO, the
algorithm should be specified in this draft, where the requirement to carry the
Priority is defined so that the extensions draft(s) can show how to implement
it in OSPF (or any other protocol)..not the other way around.
[Alia] The Root Selection is described in draft-ietf-rtgwg-mrt-frr-architecture
in Sec 7 as
'"GADAG Root Selection Priority: Among the routers in the MRT Island and with
the highest priority advertised, an implementation MUST pick the router with
the highest Router ID to be the GADAG root."
This goes back to my comment above about the capabilities and the default
profile definition: If this is part of the algorithm it should be specified in
the algorithm draft, not somewhere else.
. . .
1. Algorithm Alternatives and Evaluation. There are a couple of
alternatives described in the appendices, but there is no evaluation as to why
the Lowpoint Algorithm is better. In fact, the text seems to read as if the
appendices describe options to the main algorithm (?) -- begging the question,
are there instances where these options would/could be used?
[Alia] True - in our initial evaluations, we didn't find significant
differences in the path lengths for the alternates. Chris Bowers can comment
on that a bit. I thought that I'd cleaned up the text in the main draft to
clarify that the lowpoint algorithm - which has much less computation - is
preferable. Can you point to where the algorithms in the appendices are
considered equivalent? I will, of course, take another read through as well -
trying to reduce that issue.
Where in the main draft? And by "main draft" do you mean the architecture one?
My point was that you are presenting options to the proposed algorithm that are
not used..but there is no clear explanation as to why not (at least not that I
found in this draft). IOW, I think that if these options are not part of the
main algorithm then you should explain why not (but you already said above that
there weren't significant differences in the results), or just take them out to
avoid confusion.
. . .
1.
* "UNDIRECTED/OUTGOING/INCOMING" These are used in the algorithm in
various points, but are not really defined as to
[Alia] umm, how would you define them beyond their obvious meaning? Outgoing
is from the interface's router to the remote end. Incoming is from the remote
router to the interface's router.
:-)
The text starts talking about marking the links (and even the pseudo-code uses
the terms), but they are not defined. Yes, I can guess what they mean..but if
we want consistency you don't want people guessing.
. . .
1. Algorithm Evaluation. While it is interesting to see MRT compared to
rLFA, it would be much more interesting to see it compared to the options in
the appendices or to ARC. I would move the comparison to rLFA to an appendix.
[Alia] It is being compared to other options that are being seriously used for
fast-reroute. That includes rLFA. I don't understand why you think the
comparison isn't relevant? We didn't quite have time to get the comparison
fully done for MRT lowpoint compared to the SPF-based and hybrid versions. I
think that is something we can add - but again, we didn't find a significant
impvorement.
I didn't say that the comparison is irrelevant..I just said that I would move
it to an appendix.
In this draft you're proposing an algorithm to be used as the default in MRT.
We already know that rLFA can't always provide 100% coverage. I think that
comparing the proposed algorithm to something that we know doesn't provide the
same coverage is interesting, but it doesn't illustrate why this algorithm
should be the default — it just proves that "the 100% coverage provided by MRT
comes at the expense of a modest increase in alternate path length." That is
an interesting result..I just find it purely informational wrt to the contents
and objective of the draft.
OTOH, if the algorithm was to be compared with other potential candidates
(including the options in the appendices) then it could provide better
justification..and it would fit better in a section titled "Algorithm
Alternatives and Evaluation" that starts with the following text: "This
specification defines the MRT Lowpoint Algorithm, which is one option among
several possible MRT algorithms. Other alternatives are described in the
appendices."
Nits:
1. Section 2. "standard pseudo-node representation" Reference?
[Alia] Do you just want me to refer to OSPFv2? I can go hunt a reference for
better normative explanation or just describe transforming all broadcast
interfaces into a pseudo-node with p2p links with appropriate costs.
I usually think about ISIS when I think about pseudo-nodes..which is why we
need a reference to that the "standard representation" is. ;-)
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
