Re: [rrg] rrg Digest, Vol 44, Issue 4

[Mohamed Faye <[e-mail]>]

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, <[e-mail]> 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
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> 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 ([e-mail])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 10 Nov 2012 18:38:57 -0700
> From: Shane Amante <[e-mail]>
> To: [e-mail]
> Subject: Re: [rrg] RRG to hibernation
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Nov 10, 2012, at 10:35 AM, Danny McPherson <[e-mail]> 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 <[e-mail]>
> To: Tony Li <[e-mail]>
> Cc: [e-mail], Noel Chiappa <[e-mail]>
> Subject: Re: [rrg] RRG to hibernation
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: Eliot Lear <[e-mail]>
> Cc: [e-mail], Noel Chiappa <[e-mail]>
> Subject: Re: [rrg] RRG to hibernation
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=windows-1252
>
>
> On Nov 11, 2012, at 2:22 AM, Eliot Lear <[e-mail]> 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: [e-mail]
> To: [e-mail], [e-mail]
> Cc: [e-mail]
> Subject: Re: [rrg] RRG to hibernation
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> An: Noel Chiappa <[e-mail]>
> Cc: rrg <[e-mail]>
> 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
>
> [e-mail] wrote:
>
>     > From: Tony Li <[e-mail]>
>
>     > 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
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg
> _______________________________________________
> rrg mailing list
> [e-mail]
> 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
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg
>
>
> End of rrg Digest, Vol 44, Issue 4
> **********************************
>