Hello all, Am new to this working group, and I found some of the topics been discuss are really good. But I will like to know what are the most recent topics to caught up with.
Regards MFAYE On Nov 11, 2012 8:00 PM, <rrg-requ...@irtf.org> wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > http://www.irtf.org/mailman/listinfo/rrg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send rrg mailing list submissions to > rrg@irtf.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.irtf.org/mailman/listinfo/rrg > or, via email, send a message with subject or body 'help' to > rrg-requ...@irtf.org > > You can reach the person managing the list at > rrg-ow...@irtf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rrg digest..." > > > Today's Topics: > > 1. Re: RRG to hibernation (Shane Amante) > 2. Re: RRG to hibernation (Eliot Lear) > 3. Re: RRG to hibernation (Tony Li) > 4. Re: RRG to hibernation (heinerhum...@aol.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 10 Nov 2012 18:38:57 -0700 > From: Shane Amante <sh...@castlepoint.net> > To: rrg@irtf.org > Subject: Re: [rrg] RRG to hibernation > Message-ID: <81767641-8399-466d-a9f2-f2c07d3bb...@castlepoint.net> > Content-Type: text/plain; charset=us-ascii > > > On Nov 10, 2012, at 10:35 AM, Danny McPherson <da...@tcb.net> wrote: > > On Nov 10, 2012, at 12:24 PM, Tony Li wrote: > [--snip--] > >> I agree that some security needs to be deployed. I'm not convinced > that it needs to be BGPSEC. We've muddled along for many years and never > found the gumption to actually deploy anything. Must not be important to > people. I don't get it, but that's the observable behavior. > >> > >> In any case, this doesn't seem like a research topic. This is pretty > clearly an engineering issue. > > > > I don't agree. The engineering solution that SIDR is actively working > (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's no > tomorrow. The USG has stated intentions of "expediting secure routing work > through the Internet standard process" and "fostering adoption through > government procurement vehicles". > > > > As an operator this scares the hell out of me, especially considering > what they've designed is largely a system to control "what's routed on the > Internet and by whom". They can't seem to do anything in BGP(SEC) without > introducing the equivalent of "periodic updates", and undoing all the > goodness of things like update packing completely. > > > > Some serious thinkers working on this problem would be goodness... > > Let me add that I share Danny's concerns ... > > However, let me try to take a step back and share with everyone a much > broader set of, potentially, architectural concerns that I'm not sure this > RG considered during the last round. > > BGP was originally designed for flooding of reachability information. > But, reachability information is the end-result /after/ the application of > _routing_policy_, describing "intent", by operators of individual networks > based on various contractual agreements they have with parties whom they > directly interconnect. Assuming you agree with this premise, this presents > a paradox from a security PoV. Specifically, if a downstream network does > not have visibility into its upstream network's routing policy is it > practical/feasible for the downstream network to understand the _intended_ > propagation of reachability information and, ultimately, connectivity? > Furthermore, is it feasible to carry such information within the control > plane itself? Or, should the control plane be relegated to carrying > [strictly] reachability information in real-time, while offboard systems > carry accompanying routing policy and security information in order to > assist in making "optimal" Inter-Domain rou > ting/forwarding decisions? > > A second concern is also related to the original design of BGP and what it > has organically involved into, today. Specifically, BGP is /also/ now > being tasked as a generic "message bus" and service discovery mechanism. > Not to pick on anyone, in particular, but the following are recent > examples that come to my mind wrt this trend: > http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-01 > http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 > ... and, there may be others. Although, contrast those proposals with > what should be most concerning to people in this RG, and in the IETF: > > http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 > In short, operators (such as myself) are _extremely_ concerned that a > single erroneous update results in a complete reset of BGP sessions. Due > to the overwhelming success of BGP, it's now (and, has been for a while) a > mission-critical protocol, thus such catastrophic session resets -- caused > by a single malformed UPDATE -- are widely visible/impactful. This impact > is compounded by the 'cost to recover'. Namely, due to the large and > growing amount of information in the RIB (again, not just reachability, but > also service-discovery and completely orthogonal information), it takes > longer to exchange RIB information and, ultimately, restore services. Is > this really the best we, as an industry, can do? > > While the IETF IDR WG has been looking at mechanisms for how BGP may > defend against certain types of erroneous BGP UPDATE's for external BGP > sessions: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 > ... there does not appear to be any [straightforward] answer with respect > to internal BGP sessions, given the requirement that BGP speakers internal > to an AS must have a globally consistent RIB and FIB, otherwise packet > forwarding loops will result. And, in my personal operational experience > it's _rarely_ the case that malformed UPDATE's are detected at the first > ASBR (attached to an eBGP neighbor) in my AS, thus it concerns me that > mechanisms such as draft-ietf-idr-error-handling-02 are an adequate > solution to the problems we experience. IOW, as an operator I desire > "defense in depth" where a heterogeneous mix of vendor equipment (HW + SW), > participating as interior BGP speakers, have mechanisms to detect *and* > automatically recover from malformed UDPATE's received over iBGP sessions. > This is another area that I would point research colleagues toward. > > So, this raises the classic conundrum of: increasing complexity, > increasing RIB (and FIB) size information coupled with a contrasting need > from operators who are concerned about the robustness of the protocol and > the requirement to NOT sustain any failures[1]. Something's got to give. > > Ultimately, this makes me question whether it's no longer _just_ growth of > RIB (and, FIB) size that this RG should be (primarily?) focused on. > Rather, will the requirements for: > a) operational robustness, in the face of critical messaging errors in an > Inter-Domain Routing Protocol, which the IETF may be unable to address on > its own; > b) designing security as a first-class principle of an Inter-Domain > Routing Protocol -- either carried within or outside of control-plane > reachability information > c) increased scalability of RIB (and, other?) information > ... lead us down a path of considering we may be approaching the > end-of-the-road for BGPv4 and we need something new? > > Does anyone on this list share similar concerns wrt operational > robustness, time to recovery and (then) scalability of BGPv4? > > -shane > > [1] It is not cool to suggest that operators should just stop asking for > new features and we wouldn't have this problem. :) > > > ------------------------------ > > Message: 2 > Date: Sun, 11 Nov 2012 11:22:17 +0100 > From: Eliot Lear <l...@cisco.com> > To: Tony Li <tony...@tony.li> > Cc: rrg@irtf.org, Noel Chiappa <j...@mercury.lcs.mit.edu> > Subject: Re: [rrg] RRG to hibernation > Message-ID: <509f7c59.7080...@cisco.com> > Content-Type: text/plain; charset=UTF-8 > > Tony, > > First, thanks for taking on and navigating work within the RRG for as > long as you have done. I think people forget that this group has > induced a tremendous amount of stress and turbulence over time, and that > you were often the target of that stress. > > This having been said, I think this group like any other group ? based > on contributions and participation. If there are no contributions and > if there is no participation, no work can continue. On the other hand, > when there are contributions or participation, we shouldn't be hasty in > closing the effort. Therefore, I would suggest a solicitation for new > topics with the threat of closure, before actually closing ? or going > dormant. > > Eliot > > > ------------------------------ > > Message: 3 > Date: Sun, 11 Nov 2012 09:45:33 -0800 > From: Tony Li <tony...@tony.li> > To: Eliot Lear <l...@cisco.com> > Cc: rrg@irtf.org, Noel Chiappa <j...@mercury.lcs.mit.edu> > Subject: Re: [rrg] RRG to hibernation > Message-ID: <df11188a-3d05-4d75-8c07-7ed42b146...@tony.li> > Content-Type: text/plain; charset=windows-1252 > > > On Nov 11, 2012, at 2:22 AM, Eliot Lear <l...@cisco.com> wrote: > > > This having been said, I think this group like any other group ? based > > on contributions and participation. If there are no contributions and > > if there is no participation, no work can continue. On the other hand, > > when there are contributions or participation, we shouldn't be hasty in > > closing the effort. Therefore, I would suggest a solicitation for new > > topics with the threat of closure, before actually closing ? or going > > dormant. > > > Eliot, > > Thanks, but as you may recall, we did do a solicitation of new topics some > time ago. It didn't provoke anything substantive and there has been no > additional input. > > Further, the transition to hibernation is easily reversed if and when a > new substantive topic presents itself. > > Tony > > > > ------------------------------ > > Message: 4 > Date: Sun, 11 Nov 2012 14:52:57 -0500 (EST) > From: heinerhum...@aol.com > To: s...@internet2.edu, j...@mercury.lcs.mit.edu > Cc: rrg@irtf.org > Subject: Re: [rrg] RRG to hibernation > Message-ID: <8cf8e5d4815a51e-914-3a...@webmail-m019.sysops.aol.com> > Content-Type: text/plain; charset="utf-8" > > > I an not pleased ether. > One group goes ahead with LISP-DDT, which is doomed to fail ! With drums > and trumpets! As sure as the Amen in church ! With no rescuing trick in > sight! > The other group believes in IPv6. I admit, I don't know what is special > about IPv6. All I know is that the inventors came up with a crazy address > space and I do remember voices from many many years ago which proclaimed > the advent of the internet for our galaxy.I am sure, IPv6 would only create > additional scalability problems. Imagine a future where we have only IPv6. > Hereby imagine New York at New Year's Eve and several hundred thousand > people operating as mobile sender's of IPv6-multicast instances with > multicast receivers far away (which may as well be mobile) ! We wouldn't > not only have a scalability problem wrt forwarding but as well with respect > to identifying the individual entities. How many IPv6-addresses are needed > to identify one single mobile multicast instance? 1? 2? 3? How should it be > retrieved by software? > > > Loc/id-split: > Obviously what is a locator and whether there are several components > thereof or not hasn't been understood. > A unicast locator MUST BE location-indicating! A multicast -locator CANNOT > but this doesn't mean that there can't be any. > > > Topology-aware BGP: > Distance Vector versus Dijsktra. > DV will never tell you about the upstream network (see also Shane Amante's > email). This is a disaster if you want to manage traffic load (balance/ > dissolve congestion) :-( > Reachability: We don't need reachability. we only need to know where is > the indicated location !!! Location based routing means no user > reachability dissemination, only location reachability dissemination! > > > Whenever I addressed these issues it was like I had sinned against some > holy paradigm. > > > And we are far away from better routing: > I you only know the ALL-Nodes-Spanning-Tree (and not the > All-Links-Spanning-Tree) then you call it Spanning Tree per se. > If you only know the Unicast-FIB (and not a Multicast-FIB, nor a > Anycast-FIB) then you call it FIB per se. > > > To reach a higher level you must view things from a greater distance and > sometimes leave the old trails behind you. > > > Ich habe fertig > Heiner > > > > > > > > > > > > > > > > > > -----Urspr?ngliche Mitteilung----- > Von: Scott Brim <s...@internet2.edu> > An: Noel Chiappa <j...@mercury.lcs.mit.edu> > Cc: rrg <rrg@irtf.org> > Verschickt: Sa, 10 Nov 2012 4:40 am > Betreff: Re: [rrg] RRG to hibernation > > > Well, this will be fun. Yes Noel, you're right, this group didn't produce > any > routing revolutions, and loc/id separation is about problems on the > identity > function side, not routing ... but this group's best accomplishment imho > was to > understand that and spread the knowledge. > > Now I'll go back to doing good things with higher layer identities. Ciao. > > Scott > > j...@mercury.lcs.mit.edu wrote: > > > From: Tony Li <tony...@tony.li> > > > The publication of these RFCs concludes our long standing work item > on > > a revised routing architecture. > > Separation of location and identity is very desirable, but it has basically > nothing to do with routing (other than removing identity functionality from > the names used for routing, making them a bit more tractable). > > We still have the same old kludgy BGP global routing system we always had, > and _nothing_ has been proposed to improve/replace it. > > > The group has ... helped push the boundaries of routing farther > > forward. > > Nonsense. It has produced no routing work at all. > > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.irtf.org/mail-archive/web/rrg/attachments/20121111/fcb62568/attachment.htm > > > > ------------------------------ > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > > > End of rrg Digest, Vol 44, Issue 4 > ********************************** >
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
