Replies in-line as always...
On Thu, Oct 10, 2013 at 10:12 AM, Alvaro Retana (aretana) <[email protected] > wrote: > On 10/9/13 5:06 PM, "Alia Atlas" <[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.. > [Alia] Right - the algorithm is one aspect of a profile - and different profiles can be specified. > 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:". > [Alia] Sure - I expect that we co-authors should go over the arch draft and make sure that the normative details are clearly specified as such and clearly. In this case, I think it's just reordering a bit - since the architecture draft talks about the concept of MRT profiles and that there is a default MRT profile before defining what that default is. I don't expect to have that done for this IETF - unless there is serious concern about a lack of clarity. > 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? > [Alia] I didn't think so (but you knew that ;-) - having it make sense to define the default MRT profile where the concept of MRT profiles is defined. I do agree that it makes sense to have the algorithm draft reference the architecture draft and that the lowpoint algorithm is used in the default MRT profile - so basically say it in both places :-) > > . . . > > > >> 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. > [Alia] Absolutely. > . . . > > >> 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. > [Alia] Ah - the GADAG root selection is part of the MRT profile but not, IMHO, part of the algorithm... The same Lowpoint algorithm can be used with different GADAG root selection. For example, for multicast, one might do an MRT profile where the multicast S is picked to be the GADAG root - and the same Lowpoint algorithm is run. > > . . . > > > >> 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? > [Alia] Sorry to have been unclear - by main draft I meant the algorithm draft that isn't in the appendices. 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. > [Alia] Sure - I put them in an appendix while we decided which to do :-) . . . > > >> 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. > [Alia] True... I do describe everything about how they are used - but I'll try for better text too. . . . > > >> 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. > [Alia] AH - I am trying to show that MRT Lowpoint is a good fast-reroute mechanism that offers 100% coverage with good computation and without causing absurdly long alternates (in most/many networks). In that context, the comparison is to the "optimal" and Remote-LFA is to help show what the trade-offf for alternate length is. If we want to see if a different MRT algorithm gives better alternate lengths, that is also interesting but comes at a computational cost. > > 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." > [Alia] Yes - I should have cleaned that text up. We'll try for some comparison results - if not in time for this IETF - then shortly after. > >> 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. ;-) > Sounds like spelling it out to be a representation where all links are p2p and the necessary pseudo-nodes are added to make it so - basically the same network graph as an SPF is run on.... Alia
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
