Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Mon, 8 Aug 2005 16:41:56 +0200

Hi Curtis,

Thanks for your feedback. 
Some comments inlined

> >  
> > Curtis,
> >  
> > Thanks for reading the draft, some comments:
> >  
> > If you've got a 2.5 gig line card and want to upgrade it to 
> a 10 or 40 
> > gig line card, I still think you need to shut down the BGP session 
> > that is running on it and in order to replace the card.
> 
> Only if its an EBGP session.  If its IBGP you don't need to 
> take down anything to replace a card unless your network has 
> no internal redundancy.

OK
 
> For the EBGP session we already have BGP Gracefull Restart 
> but that doesn't cover upgrading if you are going to pull the 
> old card.

OK. 
The draft cover the case when the forwarding cannont be preserved, so
Gracefull Restart cannot be used.
 
> The forwarding that is kept in place during gracefull restart 
> won't be in place while neither card is in the slot.  Are you 
> suggesting that the BGP session should stay up and maintain a 
> black hole while the cards are swapped? 

No. We are suggesting to advertise the planned failure before the
forwarding is shut down. In such a way that no or minimal traffic is
lost.

> I hope not and 
> that's not what I read.
> 
> In this particular example, both providers would bring up the 
> 40 Gig and then bring down the 10 Gig.  Of course since a lot 
> of 40 Gig interfaces are really concatonated 10 Gigs (4 x 
> OC192), in this example they'd add 3 10 gigs with no 
> disruption at all.  Either way no bits are lost if for a time 
> there are two peerings before the old one is shut down.
> Of course if you are out of card slots there are some routers 
> that let you expand the backplane without disruption.  Not 
> all routers do that.

For sure.
Not all routers are even capable of keeping forwarding up during a
control plane switch over...
 
> > Of course you can do it gracefully with some route-map tricks, ...
But 
> > on large operationnal routers it can be quite complex, and it would
be 
> > better to have it automatic and directly embedded in the router
software.
> 
> Sorry.  I used to maintain a tier-1 network and I can't see 
> why it would be so difficult to change policy to not 
> advertise the EBGP into IBGP, then not accept the EBGP, then 
> shut down the EBGP.  Yes, I know that today's NOC staff are 
> not what they used to be but many of our NOC staff were 
> college students who didn't know what BGP was until their on 
> the jub training.  It seems that this would be your best solution.

I don't see the point of doing it manually each time when it can be
automated if we agree on a way to do it and have it implemented.
 
> In the old days some bright operations engineer might write a 
> perl program which given a peering line could write the 
> policy to disable the EBGP to IBGP, then disable the EBGP, 
> then take down the peering.
> The operator could then paste that into the router config.  
> It sounds like what you are asking for is a way for the 
> router to shut down the peering in a similar order but do so 
> automaticly.

Yes.
We're asking for a way to do it with minimal packet loss in all typical
situations. I'm not sure this is that obvious. If you belive it is,
could you please send an URL with the procedure?
And to have it down automaticly by the router itself.

> > BTW, graceful restart is really efficient when all (all !) peers are

> > supporting it.If some of the peer are not supporting it, I wouldn't 
> > say it's harmful but ... You never know. I do not know many service 
> > providers who can successfully use it on a large ASBRs 
> currently. In  our case many of our customers and peers do not support
GR even in 
> > helper only mode. So GR is still a "for future use" feature to me.
> 
> The document that you are asking to be considered looks to be 
> just a requirements document.

It is.
It does'nt seems so easy to first agree on the requirement.
 
> What you might be better off advocating is that more routers 
> implement BGP gracefull restart and more or your peers enable 
> it.  In the example you just gave gracefull restart doesn't 
> help.  Given the draft and then the example above, its not 
> clear what problem you are trying to address and what 
> solution you have in mind.  Is it time for me to reread the draft?
> 
> > > If you are taking a router completely out of service you 
> can cost it 
> > > out of the IGP first then take down the EBGP peerings, 
> then shut it 
> > > down.
> >  
> > This is not going to work in all situations.
> 
> Yes but your document adds nothing to improve it.

We raise the issue, which is a first step.

> > Best regards
> > Nicolas Dubois
> > Tel :  0144442817	
> Regards,
> Curtis

Regards,
Bruno

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 14 Aug 2005 20:20:00 -0400

In message <[email-masked]>
> We raise the issue, which is a first step.

OK.  You've successfully raised the issue.  Thanks for doing so.
There may not be a need for a separate RFC to raise the issue if the
issue can be clearly and very concisely stated and if there is a very
simple solution.  So lets consider solving it for a moment.

If you are trying to remove routes from your own IGP costing out is
the best solution.  In ISIS you use the OVERLOAD bit.  In OSPF you can
cost out all links.

For the case where you are removing EBGP learned routes from your own
IBGP you can cost out your advertisements with a high LOCAL_PREF.
Costing out with LOCAL_PREF is better than sending MP_UNREACH since no
router is ever temporarily without a route if an alternate exists but
the advertisement is suppressed by normal BGP rules including RR
topologies.

For this case at most you could ask your favorite router vendor for a
"poison-peer" command that changes the LOCAL_PREF of all routes to a
very high value (make up your own keyword and syntax which specifies
the peer and value).  If taking the whole router down, then a
"poison-peer all" or "poison-self" variation would be handy.

For the benefit of your peer, prior notification to their NOC of your
maintenance is still needed if you plan to take an EBGP session down
or take a router down.

For the benefit of your peer router some indication that its time for
them to "cost out" your routes (or poison your peering in the above
terminology) might help.  The advantage of using a CEASE subcode is
that any router that doesn't understand will just treat it as any
other CEASE.  Backwards compatibility is always nice.  If both routers
understand, they'd just LOCAL_PREF poison each side of the peering and
then after some delay (probably best to specify a default and
"configured on the local router") send MP_UNREACH for all the routes.
A disadvantage of a CEASE subcode is that if a specific prefix went
unreachable there is no longer a way to send an MP_UNREACH across the
peering, unless this is made a non-fatal CEASE to be followed by
another CEASE very shortly.

If I'm not mistaken, then all that is needed is an internet-draft with
a CEASE subcode and some wording to indicate that it should be treated
as non-fatal and result in both sides setting a very high LOCAL_PREF
for all routes on the peering regardless of local policy.  I suggest
that each router should enforce a maximum time to keep the peering
after getting one of these CEASE, making sure that it is only used as
a temporarily non-fatal policy override.

Lets see what other on the IDR list have to say about this as a
potential solution.

Curtis