Re: [GROW] I-D Action:draft-ietf-grow-va-auto-00.txt

[Xu Xiaohu <[e-mail]>]

Sorry for late response.

IMHO, if the packets need to be tunneled to the APRs by the ingress routers
(e.g., in case that legacy BGP routers and VA-enable BGP routers coexist
within a given AS), one can adopt the methods used for BGP free core (e.g.,
the BGP Encapsulation Extended Community defined in
[draft-ietf-softwire-encaps-safi] ) to realize it. If all the BGP routers
within a given AS are VA-enabled, it is not necessary to use tunnels between
the ingress routers and the APRs.

Yes, we need to state it clearly in the next version of the related draft.

Xiaohu

> -----邮件原件-----
> 发件人: Paul Francis [mailto:[e-mail]]
> 发送时间: 2009年10月24日 5:06
> 收件人: Joel M. Halpern
> 抄送: [e-mail]; Xu Xiaohu
> 主题: Re: 答复: [GROW] I-D Action:draft-ietf-grow-va-auto-00.txt
> 
> "Joel M. Halpern" <[e-mail]> wrote on 10/22/2009 08:10:57 PM:
> 
> 
> >
> > It seems to me that if we are going to double-tunnel, then it is
> > important that the Virtual Aggregates be marked with a specific
> > community, since the router using those routes need to know that it
> > should tunnel that traffic.  (While such may be inferable from the
> > can-suppress, being explicit is much better than drawing conclusions.)
> >
> 
> Now that you point this out, I think this is a bug in the "can suppress"
> method.  The configured VP-list approach, as well as the VP-route tag make
> it clear what the VPs are, so that tunneling to the APR can be done.  The
> "can suppress" approach removes knowledge of the VPs per se, so we lose
> the ability to really know when we need to tunnel.
> 
> Xiaohu, do you have any thoughts?
> 
> PF
> 
> 
> > Yours,
> > Joel
> >
> > Paul Francis wrote:
> > > Just in case Xiaohu's point is not clear....the exact looping problem
> you
> > > describe does not occur because packets are tunneled to APRs.  This is
> 
> > > made clear in draft-ietf-grow-va-00.
> > >
> > > PF
> > >
> > >
> > >
> > >
> > > From:
> > > Xu Xiaohu <[e-mail]>
> > > To:
> > > "'Joel M. Halpern'" <[e-mail]>, 'Paul Francis'
> > > <[e-mail]>
> > > Cc:
> > > [e-mail], [e-mail]
> > > Date:
> > > 10/21/2009 06:16 AM
> > > Subject:
> > > 答复: [GROW] I-D Action:draft-ietf-grow-va-auto-00.txt
> > >
> > >
> > >
> > > Hi Joel,
> > >
> > >> -----邮件原件-----
> > >> 发件人: Joel M. Halpern [mailto:[e-mail]]
> > >> 发送时间: 2009年10月21日 3:55
> > >> 收件人: Paul Francis
> > >> 抄送: [e-mail]; [e-mail]
> > >> 主题: Re: [GROW] I-D Action:draft-ietf-grow-va-auto-00.txt
> > >>
> > >> First, to be clear, the loop conditions I was raising for the
> > >> autoconfiguration are transient.  They are not persisetnt loops.  I
> > >> would ignore them except for the large number of prefixes (and
> therefore
> > >> potentially large amount of traffic) that could be affected.
> > >>
> > >> The basic situation is, given a chain of routers
> > >> A - B - C - D - E ...
> > >> Suppose that for some prefix(es), B is the VP Aggregator, and the
> > >> correct exit is E or past E.
> > >> Now suppose that C happens to be a busy router, doing other control
> > >> computations.  If necessary, assume additional connectivity for the
> > >> announcements getting to C and D (maybe B, C, and D all talk to a
> route
> > >> reflector F.)
> > >> Suppose that C and D have gotten the advertisement telling them that
> the
> > >> individual paths are reachable via E or something past E.
> > >> Suppose that C and D both get the VP-tagged router advertisement from
> B.
> > >> But C is busy and does not update his FIB for many seconds.  D
> however
> > >> happens to get his timing better aligned with the advertisements, and
> > >> updates his FIB.
> > >>
> > >> At that point, any packets destined to the covered prefixes, which
> > >> arrive at D will be sent to C, towards the VP Aggregator B.
> > >> However, C still thinks that the exit is somewhere past E.  So it
> sends
> > >> the packets right back to D.
> > >> (This is somewhat akin to the micro-loop problem in fast IP
> rerouting.)
> > >
> > > Yes, this transient loop will occur as long as the routes (either on
> > > control
> > > plane or data plane) on different routers are not synchronized, no
> matter
> > > whether the VA feature is turned on or not.
> > >
> > >> I am presuming for now that we are prepared to disregard the case of
> C
> > >> not having been upgraded to understand the community.  We have to
> > >> presume that all the routers have been upgraded before the feature is
> > >> turned on.  Otherwise, the problem above persists.
> > >
> > > In order to allow VA-enable routers and legacy routers to coexist
> within
> > > the
> > > same AS, the packets matching the VP route should be tunneled to the
> > > corresponding VP aggregator.
> > >
> > > Best wishes,
> > > Xiaohu
> > >
> > >> Paul Francis wrote:
> > >>> Hi Joel,
> > >>>
> > >>> I'm quite embarrassed---I don't see the loop you are referring to.
> > > Could
> > >>> you spell it out for me?
> > >>>
> > >>> FAIW, here is my analysis (within which I don't see a looping
> > >>> situation...what am I missing?).  I'm happy to clean up this
> analysis
> > > and
> > >>> include it in the draft if that is what you are asking for.
> > >>>
> > >>> First, lets consider the static configured VP-list approach
> (currently
> > >>> described in draft-ietf-grow-va-00).
> > >>>
> > >>> There are two misconfig possibilities:
> > >>> V1:  A router thinks a VP exists that doesn't actually (i.e. its
> > > VP-list
> > >>> claims that a VP exists, but there is no router that itself acts as
> > > the
> > >>> APR for that VP).
> > >>> In this case, the router expects to see a route to the VP.  If it
> does
> > > not
> > >>> see the route, then it either installs the sub-prefixes, in which
> case
> > >>> routing works fine, or it does not, in which case it drops the
> > > packets.
> > >>> (Which it does is a policy decision, subject to available FIB
> space.)
> > >>> Either way, no loop.
> > >>> V2:  A router does not think a VP exists that actually does.  In
> this
> > >>> case, the router will FIB-install the sub-prefixes and routing works
> > > fine.
> > >>> Next, lets consider VP-route tagging approach (described in
> > >>> draft-ietf-grow-va-auto-00).
> > >>>
> > >>> Here, there is no static configuration of VPs per se.  Rather, the
> > > only
> > >>> configuration is that of the APR.  When an APR advertises a
> VP-route,
> > >>> presumably it is either prepared to forward packets (i.e. it has
> > >>> FIB-installed the sub-prefix), in which case all is well, or it is
> has
> > > for
> > >>> some reason not FIB-installed one or more sub-prefixes, in which
> case
> > > it
> > >>> should drop the packet.  (There should never be a case where an APR
> > >>> forwards a packet to another APR just cause it doesn't have a route
> to
> > > a
> > >>> specific IP address.  This is a router functionality issue, not a
> > >>> configuration issue.)
> > >>>
> > >>> Lets consider the non-APRs (for a given prefix).  When it receives a
> > >>> VP-route, the route is tagged, and so the non-APR knows it is a VP.
> It
> > >>> will forward packets to the VP (for FIB-suppressed sub-prefixes), at
> > > which
> > >>> point the behavior in the above paragraph applies (the APR either
> > > forwards
> > >>> for drops the packet, but no loops).  If there is no VP-route
> anywhere
> > > for
> > >>> a given VP, the non-APR simply assumes that it is not a VP, and
> either
> > >>> installs the sub-prefixes or not, but either way no loop.
> > >>>
> > >>> If a non-APR is doing graceful restart, then until the RIB
> converges,
> > > it
> > >>> might have incorrect information, as follows:
> > >>> GR1:  It thinks there is a VP when there isn't.
> > >>> In this case, it will tunnel packets to what it thinks is the APR
> for
> > > the
> > >>> VP (say R1).  R1 will then tunnel the packet to the correct APR (if
> > > there
> > >>> is one), or drop it (if there isn't).  Is there a possible scenario
> > >>> whereby R1 thinks that some router R2 is the APR, and R2 thinks that
> > > some
> > >>> router R1 is the APR?  It is hard to imagine one.  Lets imagine, for
> > >>> instance, that both R1 and R2 are APRs at time T1.  At T1, the admin
> > >>> reconfigures them both to be non-APRs.  Then they both at the same
> > > time
> > > go
> > >>> into GR.  But this shouldn't happen, because when a router is told
> > > that
> > > it
> > >>> is no longer an APR, it will first withdraw the VP route, then wait
> a
> > >>> while (for the withdraw info to propagate), and only then
> FIB-suppress
> > > the
> > >>> sub-prefixes.   So both R1 and R2 should be able to forward to
> > >>> sub-prefixes during the GR period, and so no loop should form.  (As
> a
> > >>> further safety, we could have a rule that says that a router never
> > >>> forwards a received tunneled packet to an APR, but this seems
> > > unnecessary
> > >>> in practice.)
> > >>>
> > >>> GR2:  It does not know of a VP that exists.
> > >>> Here, the non-APR should simply drop the packets.  No loop.
> > >>>
> > >>>
> > >>> Finally, lets consider the can-suppress approach specified in
> > >>> draft-ietf-grow-va-auto-00.
> > >>> Here the concern is that the configured VP-range table does not
> match
> > >>> reality.  Again, there are two cases of concern:
> > >>> CS1:  The router thinks that an address range has a VP when there is
> 
> > > in
> > >>> fact none.
> > >>> Here the router will tag sub-prefix routes as can-suppress.  Routers
> > > that
> > >>> see this (which are non-APR routers) will FIB-suppress the
> > > sub-prefixes,
> > >>> and packets will be dropped, not looped.
> > >>>
> > >>> CS2:  The router thinks that an address range has no VP when there
> is
> > > one.
> > >>> In this case, the sub-prefix routes will not be tagged as
> > > can-suppress.
> > >>> Other routers will FIB-install the sub-prefixes (if there is FIB
> > > space),
> > >>> and packets will be forwarded correctly.  If there is not FIB space,
> > > then
> > >>> the packets will correctly be forwarded to the VP.
> > >>>
> > >>> PF
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> "Joel M. Halpern" <[e-mail]> wrote on 10/20/2009 05:20:54
> 
> > > PM:
> > >>>
> > >>>> I am glad to see this draft, as I believe this problem is a
> critical
> > >>>> obstacle in the way of the community giving VA serious
> consideration.
> > >>>>
> > >>>> I believe that there is one class of issue that is alluded to
> briefly
> > > in
> > >>>> the document, but not discussed, which needs attention for
> > > credibility.
> > >>>> That is the issue of inconsistent information.
> > >>>> As written, there is no discussion about what happens if during
> > >>>> transitions, routers have different vies of the VP routes and the
> > >>>> suppress prefix sets.  It appears that under such circumstances
> large
> > >>>> collections of traffic may loop.  (Double-tunneling would prevent
> > > this,
> > >>>> but that is not currently mandated by the base VA draft, for good
> > >>>> reason.)  Without some discussion of the problem, there will be a
> > >>>> tendency for readers to conclude that it is a major issue.
> > >>>>
> > >>>>
> > >>>> As a lesser topic, it seems to me that the inability to install
> > > prefixes
> > >>>> if the VP routers are down seems like a serious flaw in the
> > > can-suppress
> > >>>> approach.  If it is somehow not an issue, then the problems raised
> in
> > >>>> the VP-route tag discussion would seem to be even less important.
> > >>>> Either way, it seems that VP-route tag is simply cleaner.
> > >>>>
> > >>>> Yours,
> > >>>> Joel
> > >>>>
> > >>>>
> > >>>> [e-mail] wrote:
> > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts
> > >>> directories.
> > >>>>> This draft is a work item of the Global Routing Operations Working
> > >>> Group of the IETF.
> > >>>>>    Title           : Proposal for Auto-Configuration in Virtual
> > >>> Aggregation
> > >>>>>    Author(s)       : P. Francis, et al.
> > >>>>>    Filename        : draft-ietf-grow-va-auto-00.txt
> > >>>>>    Pages           : 11
> > >>>>>    Date            : 2009-10-18
> > >>>>>
> > >>>>> Virtual Aggregation as specified in [I-D.ietf-grow-va] requires a
> > >>>>> certain amount of configuration, namely virtual prefixes (VP), a
> VP
> > >>>>> list, type of tunnel, and popular prefixes.  This draft proposes
> > >>>>> optional approaches to auto-configuration of popular prefixes and
> > > the
> > >>>>> VP list, and discusses the pros and cons of each.  If these
> > > proposals
> > >>>>> are accepted, they will be incorporated into [I-D.ietf-grow-va].
> > >>>>>
> > >>>>> A URL for this Internet-Draft is:
> > >>>>> http://www.ietf.org/internet-drafts/draft-ietf-grow-va-auto-00.txt
> > >>>>>
> > >>>>> Internet-Drafts are also available by anonymous FTP at:
> > >>>>> ftp://ftp.ietf.org/internet-drafts/
> > >>>>>
> > >>>>> Below is the data which will enable a MIME compliant mail reader
> > >>>>> implementation to automatically retrieve the ASCII version of the
> > >>>>> Internet-Draft.
> > >>>>>
> > >>>>>
> > >>>>>
> > >
> ------------------------------------------------------------------------
> > >>>>> _______________________________________________
> > >>>>> GROW mailing list
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/grow
> > >>>
> > >
> > >
> > >
> > >