Hi Bill, BRDP and supplementary mechanisms support:
B1d. Semi-hierarchical numeric LOCs are dynamically assigned. Local reconnection during link state changes is accomplished with rerouting and / or renumbering. I think this variant is missing, and it is an important one (e.g. ad hoc networks). FYI: BRDP supports other strategies as well. Just repeating myself on "session identity (SID) used by the layer 4". Layer 4 is OSI terminology, and this is NOT the session layer. Counting TCP/IP model layers: the fourth is the application layer. Please reword the introduction and I am fine. Teco. |-----Oorspronkelijk bericht----- |Van: [email protected] [mailto:[email protected]] Namens William |Herrin |Verzonden: vrijdag 12 december 2008 6:02 |Aan: RRG |Onderwerp: Re: [rrg] Summary of architectural solution space | |On Thu, Dec 4, 2008 at 11:36 AM, Teco Boot <[email protected]> wrote: |> On Strategy B and H: |> I think the difference of the two strategies is minor. Make methods |A2a and |> A2b for these? | |Turns out you were right about this... | |The fifth draft is now available at |http://bill.herrin.us/network/rrgarchitectures.html | | |Major changes include: | |Strategy H is folded in to strategy B as variant B1c. Original |strategy B is B1a. |Anja's loose source routes (from HAIR) is now B1b. | | | |So, here's my master plan. I'm playing it by ear so this can still |change, but this is what I'm thinking: | |Step 1. Where we are right now. In step 1, I'll make additions based |on this criteria: You propose something architecturally different than |what's already there and I understand it well enough to form a mental |picture of how that would work. I don't have to agree; I just have to |understand. | |If I can get to a draft where there are only cosmetic changes from the |last one, I'm going to "close" the document to additions. I put close |in quotes because if something genuinely different and obviously valid |comes along I'll still add it but that'll be it for anything more |minor. | |Step 2. I ask each of you to propose eliminating one or more of the |strategies or variants on the grounds that they are in some way |unworthy of further attention. If I get a strong consensus (meaning |lots of you say yes and no more than a couple say no) then I'll remove |that strategy. | |Step 3. I'll ask for weak consensus on forming IETF working groups to |pursue specific strategy variants. Weak consensus means lots have |something to say and more agree than disagree. I'll mark them |accordingly in the document. My hunch is that two or three will pass |this hurdle, but we'll see when the time comes. | |Step 4. I'll reformat the draft as an I-D and offer it to the group as |Bill Herrin's recommendation. I'll propose that it become the RRG's |recommendation to the IETF and be published as an informational RFC. | |Beyond that, it's in your hands. If you find some other, better basis |for forming a consensus recommendation, great. If not, well, it'll be |your call. | |Regards, |Bill Herrin | | |-- |William D. Herrin ................ [email protected] [email protected] |3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> |Falls Church, VA 22042-3004 |_______________________________________________ |rrg mailing list |[email protected] |https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
