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 17:13:25 +0200

Let's put it in another way.

BGP needs to advertise the unreachability of some destinations. If BGP
had a minute before the real failure (in the forwarding plane), could it
advertise the unreachability in a way that no (or minimal) packet to
these destination were lost?

A similar topic is discused in rtg-wg with the doc
draft-francois-ordered-fib-00.txt but for the intra-AS case.

> any vendor has a hook into microsoft outlook calender with BGP? ;-)
> 
> >From: "john smith" <[email-masked]>
> >To: [email-masked], [email-masked]
> >Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG 
> >doc
> >Date: Mon, 08 Aug 2005 14:33:01 +0000
> >
> >Hi,
> >
> >What about "his" customers? His SLAs may be more stringent than your 
> >SLAs...
> >
> >I would agree with Howard in a way, GROW would be a nice 
> place to bring 
> >this up.
> >As far as i know most people rely on exchanging information 
> a few hours 
> >prior to a restart.
> >
> >>From: "DECRAENE Bruno RD-CORE-ISS" 
> <[email-masked]>
> >>To: "john smith" <[email-masked]>,<[email-masked]>
> >>Subject: RE: [idr] BGP planned maintenance requirements as 
> an IDR WG 
> >>doc
> >>Date: Mon, 8 Aug 2005 16:14:10 +0200
> >>
> >> > ....Well but if they are heavy traffic bearing links it would be 
> >> > better to inform your peers a few hours in advance so 
> that he can 
> >> > rewrite his policies.. it is also his $$ after all :-)
> >>
> >>If it's my customer (Internet or VPN) this is my $$ if I 
> broke the SLA.
> >>In a BGP/MPLS VPN situation, if I manage the CE, it's my 
> time/money to 
> >>rewrite it's policy.
> >>
> >>
> >> > >Hi John,
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I think if *we know* that a bomb is going to fall on 
> our town 
> >> > > > at X'oclock, we warn everyone to leave town beforehand....
> >> > > > and not wait till the last minute and send out a message?
> >> > >
> >> > >That's exactly our point.
> >> > >We know the forwarding will be shutdown. Why wait the 
> last second 
> >> > >to send a BGP CEASE? Why not inform all your BGP peers a few 
> >> > >seconds/minutes before? In a way that would allow minimal
> >> > packet loss
> >> > >during BGP convergence.
> >> > >
> >> > >
> >> > > > So generally most operators simply send out an 
> "email" to the 
> >> > > > peering NOCs.
> >> > > > Practical..no?
> >> > >
> >> > >Warning the peer is one thing. Shuting down the session with 
> >> > >minimal pack loss is still desirable.
> >> > >
> >> > >In some situation, we don't care about loosing some trafic
> >> > or both NOC
> >> > >we'll write some route map/policy to gracefully reroute the
> >> > packets (or
> >> > >believe so).
> >> > >
> >> > >In some other situation, customers do cares about their 
> SLA, and 
> >> > >modifying the route map each time is too error prone and 
> >> > >time/money consuming.
> >> >
> >> > _________________________________________________________________
> >> > Express yourself instantly with MSN Messenger! Download 
> today it's 
> >> > FREE!
> >> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >> >
> >> >
> >
> >_________________________________________________________________
> >Don't just search. Find. Check out the new MSN Search! 
> >http://search.msn.click-url.com/go/onm00200636ave/direct/01/
> >
> >
> >_______________________________________________
> >Idr mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/idr
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today 
> it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
> 

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

---

From: "john smith" <[email-masked]>
Date: Mon, 08 Aug 2005 17:30:14 +0000

What is wrong with tracking the state of the FT :( as specific in the GR
It is not like it is patented or something.....

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Wed, 17 Aug 2005 12:00:15 +0200

Hi Curtis, 

> From: Curtis Villamizar [mailto:[email-masked]] 

> 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.

Thank you for you proposition which seems reasonnable to me.

There are multiple solutions to advertise the planned maintenance to
eBGP peers. Using the "CEASE" message is one. To name a few, one could
also use a dynamic capability, a well-known community, a specific MED
value "MAX METRIC"... Each solution has its advantage and disadvantage.
We "just" have to agree on one; and I'm not sure to know how we should
proceed for this. (one solution draft proposing one solution, one
solution draft listing all reasonable solution and their pro & con, N
solution drafts each proposition a solution, one requirement draft ...)

I'd be pleased if you could contribute to this by writing an
internet-draft describing your solution and addressing the requirements.

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

> Curtis

Thanks,
Best regards,
Bruno

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Fri, 19 Aug 2005 13:01:56 +0530

Using community, local pref or MED would entail carrying prefixes/NLRIs,
whereas using some form of CEASE would be a simple way which would apply for
the entire session.

 I would vote for a single draft discussing the pros and cons of all
approaches along with the recommended approach as a good start.

Regards,
Vijay
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> DECRAENE Bruno RD-CORE-ISS
> Sent: Wednesday, August 17, 2005 3:30 PM
> To: [email-masked]
> Cc: [email-masked]; FONDEVIOLE Benoit RD-CORE-ISS; DUBOIS Nicolas
> ROSI-DAS-ARI
> Subject: RE: [idr] BGP planned maintenance requirements as an 
> IDR WG doc
> 
> 
> 
> Hi Curtis, 
> 
DISCLAIMER 
This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies 
and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the 
individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to 
read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, 
please notify the sender immediately by return e-mail and delete it from your computer