Subject: [Idr] Soft-Notify as an IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Mon, 26 Apr 2004 08:01:36 -0700

Folks,

Please comment on the attached. The deadline for comments is
May 10.

Yakov.

------- Forwarded Message

Date:    Tue, 20 Apr 2004 12:47:27 -0700
From:    Gargi Nalawade <[email-masked]>
To:      [email-masked]
Subject: [Idr] Soft-Notify as IDR WG document

Hi All,

I would like to request that BGP Soft-Notify draft,
draft-nalawade-bgp-soft-notify-00.txt be accepted as
an IDR WG document.

- -Gargi

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

------- End of Forwarded Message

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

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 10:04:09 -0700 (PDT)

Yakov Rekhter writes:

> Folks, Please comment on the attached. The deadline for comments is
> May 10.

I dont think this document should be accepted as a work-group
document. The unit of containment in bgp should be the session. We can
possibly have multiple sessions between a pair of systems either via
manual config or with the mecanism that Scudder is proposing.

Attempting to reset a subset of the nlri is something that won't work
in a considerable number of cases and that adds a very significant
ammount of complexity to BGP.

I would like to propose that the WG rejects this approach.

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 10:04:09 -0700 (PDT)

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 26 Apr 2004 11:38:33 -0700 (PDT)

> Please comment on the attached. The deadline for comments is

I don't think this document should be accepted as a WG document. Resetting
some of the nlris on the same session will not help in a several cases and
adds complexity. Also such an attempt at partial recovery may lead to the
session continuing to operate in a faulty/corrupted state.

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 26 Apr 2004 11:38:33 -0700 (PDT)

rahul

---

From: "zafar ali" <[email-masked]>
Date: Mon, 26 Apr 2004 15:22:57 -0400

Hi, 

Yes, this document should be accepted as a WG ID. 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of Yakov Rekhter
>Sent: Monday, April 26, 2004 11:02 AM
>To: [email-masked]
>Subject: [Idr] Soft-Notify as an IDR WG document
>
>
>Folks,
>
>Please comment on the attached. The deadline for comments is May 10.
>
>Yakov.
>
>draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG 
>document.
>
>- -Gargi
>
>

---

From: "zafar ali" <[email-masked]>
Date: Mon, 26 Apr 2004 15:22:57 -0400

Hi, 

Thanks

Regards... Zafar

---

From: Andrew Lange <[email-masked]>
Date: Mon, 26 Apr 2004 13:33:30 -0700

This draft should be accepted by the WG.  It provides a valuable mechanism 
for today's deployments where we have multiple NLRI in a single session.

Andrew

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 14:06:06 -0700

There are a large number of cases that are frequently hit eg. reaching
a Max-prefix limit, admin shutdown, user reset (clear) of a safi, etc
where it is unnecessary to penalize other afi/safis that run on the same
session. Of course one could limit one afi/safi per session, but unless
we change the BGP Spec to force one session per every afi/safi, the
reality is going to be that multiple afi/safis would share a single
session. If we are talking of changing BGP semantics as it exists
today that is a separate issue and independant of this document. This
document addresses the problem that exists with today's semantics. It
is important that we address today's reality of today's BGP semantics
and avoid penalizing the other afi/safis that share the same session
in case of errors/actions on any one of them.

Hence I propose that this be accepted as a WG document.

-Gargi

---

From: Andrew Lange <[email-masked]>
Date: Mon, 26 Apr 2004 13:33:30 -0700

Andrew

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 14:06:06 -0700

-Gargi

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 14:55:25 -0700 (PDT)

Gargi Nalawade writes:

> There are a large number of cases that are frequently hit
> eg. reaching a Max-prefix limit, admin shutdown, user reset (clear)
> of a safi, etc where it is unnecessary to penalize other afi/safis
> that run on the same session.

How do you recover from those conditions ? notification is just 1/2 of
the problem... its isn't enought to address somethis partially.

> Of course one could limit one afi/safi
> per session, but unless we change the BGP Spec to force one session
> per every afi/safi, the reality is going to be that multiple
> afi/safis would share a single session.

why is that ? with the multisession appoach you can give the operator
a pratical way to select the unit of cotainment that it desires.

There of course trade-offs in such a choice, such as an increase in
the number of objects that need to be monitored from an ops point of
view, but the same issues do exist with what you a proposing.

> If we are talking of
> changing BGP semantics as it exists today that is a separate issue
> and independant of this document. This document addresses the
> problem that exists with today's semantics. It is important that we
> address today's reality of today's BGP semantics and avoid
> penalizing the other afi/safis that share the same session in case
> of errors/actions on any one of them.

You seem to be considering just a subset of the shared fate implied in
a bgp session, which btw isn't necessarly a bad thing.
The multisession approach seems to me to cover all the scenarios that
you describe plus issues that you do not address.

> Hence I propose that this be accepted as a WG document.

I maintain my opposition.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 14:55:25 -0700 (PDT)

Pedro.

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 15:05:31 -0700

> the problem... its isn't enought to address somethis partially.

Pls read the draft. It describes how.

> a pratical way to select the unit of cotainment that it desires.

In which case you would still end up containing multiple afi/safis
over one session. So we are back to square one.

> view, but the same issues do exist with what you a proposing.

Not really. The soft-notofication does not affcet the number of objects
being tracked etc. Everything else stays exactly the same. The afi/safi
demarcation is as specified by the BGP Spec today, Soft-Notify does not
touch it. If you do, then that would be an implementation limitation or
issue.

> The multisession approach seems to me to cover all the scenarios that

Multisession and soft-notify are complementary solutions. The former
aims at separating out at the session level and gives a way to automate
establishing separate sessions per afi/safi. The latter addresses the
problem with today's spec which allows operators to have one session
carrying multiple afi/safi's, but penalizes the other safis in case of
operations that require reetting of only that afi/safi.

> you describe plus issues that you do not address.

Like which ones?

-Gargi

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 15:28:59 -0700 (PDT)

Gargi Nalawade writes:

> Not really. The soft-notofication does not affcet the number of
> objects being tracked etc. Everything else stays exactly the
> same.

That is an unrealistic claim..
The network operator needs to know that a given set of functionality
is working. If you split a set (session) such that parts can fail
independently that needs to be monitored.

> The afi/safi demarcation is as specified by the BGP Spec
> today, Soft-Notify does not touch it. If you do, then that would be
> an implementation limitation or issue.

Changing the operational model for BGP sessions will add
complexity in terms of management. It must be a conscious tradeoff.

Again, you can achieve all this in a much simpler way by using
multisession, with variable degrees of granularity.

> >>If we are talking of >>changing BGP semantics as it exists today
> that is a separate issue >>and independant of this document. This
> document addresses the >>problem that exists with today's
> semantics. It is important that we >>address today's reality of
> today's BGP semantics and avoid >>penalizing the other afi/safis
> that share the same session in case >>of errors/actions on any one
> of them.

We are talking about fate-sharing of different afi/safi in a given
session. Its is the exact same issue.
If you believe you want to manage things with per nlri-type
granularity you can do it w. multisession.

Besides multisession is 10x easier to implement and deploy since it
can use existing state machines.

> Like which ones?

Like update errors which more likely than not corrupt the tcp
stream.

Please explain what can be done w. this approach that cannot be done
w/ one session per afi/safi or why, given that we are talking about a
significant development and deployment (given mgmt impact), this
approach is better than using 1 session per afi/safi.

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 15:05:31 -0700

Like which ones?

-Gargi

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 15:28:59 -0700 (PDT)

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 16:46:59 -0700

> independently that needs to be monitored.

This already exists today. Look at how Route-refresh for a particular
afi/safi works today. This is no different. Unless of course there are
implementation-specific issues.

> multisession, with variable degrees of granularity.

Lets not mix this with multisession. That is a different solution
with different tradeoffs. Let us talk about Soft-notify here, so
we can focus the discussion on the pros & cons of this one.

> session. Its is the exact same issue.

Which is as per the BGP-Spec as it exists today.

> granularity you can do it w. multisession.

Which is a different way of doing it by forcing each afi/safi on a
separate session. That too, not always. Note that even with
Multisession, multiple afi/safis can share the same session.
Soft-notify is aimed at addressing the case when multiple afi/safi's
share one session and it is desirable that operations/events in one
afi/safi do not affect the operation of the others on the same session
as itself.

> can use existing state machines.

Depends on the implementation :)

> Like update errors which more likely than not corrupt the tcp

For those cases, the draft proposes using Notifications instead of
Soft-Notifications.

> approach is better than using 1 session per afi/safi.

The point is not to force all afi/safi's on a single session. The
solution-space addressed by this document is the existing deployments
and the existing BGP-Spec where operators either have or may choose to
have multiple afi/safi's on a single session.

-Gargi

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 16:46:59 -0700

-Gargi

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 17:37:52 -0700 (PDT)

Gargi Nalawade writes:

>> That is an unrealistic claim..  The network operator needs to know
>> that a given set of functionality is working. If you split a set
>> (session) such that parts can fail independently that needs to be
>> monitored.

> This already exists today. Look at how Route-refresh for a
> particular afi/safi works today. This is no different. Unless of
> course there are implementation-specific issues.

No, sub-states within a bgp session do not exist. A session is either
working w/ all the functionality that has been configured on it, or
its is not.

> with different tradeoffs. Let us talk about Soft-notify here, so we
> can focus the discussion on the pros & cons of this one.

Lets not. What is relavant is to address a particular problem and to
consider what option to chose we must contrast several approaches.

> separate session.

so you do agree that multisession is a different way to solve the
problem.

> That too, not always. Note that even with
That doesnt mean that multisession can't be used w/ 1 session per
nlri... in fact it allows you to control exactly what granularity is
desired. 

> share one session
and why would you do that *and* want per nlri mgmt of the session ???

> Depends on the implementation :)

The deployment part of the equation doesn't...
Ops people understand the bgp state machine... its easy to add the
concept of multisession on top. Its is a much more significant
chalenge to add this per nlri up/down negotiation.

> For those cases, the draft proposes using Notifications instead of

Which doesnt provide fault containment. I'd rather have a single way
of fault containment that works across all reasons for session
failure...

>>  Please explain what can be done w. this approach that cannot be
>> done w/ one session per afi/safi or why, given that we are talking
>> about a significant development and deployment (given mgmt impact),
>> this approach is better than using 1 session per afi/safi.

> The point is not to force all afi/safi's on a single session.

But you haven't explained why that should be a goal... 

> The
> solution-space addressed by this document is the existing
> deployments and the existing BGP-Spec where operators either have or
> may choose to have multiple afi/safi's on a single session.

Why don't we consider the reasons why one would like to have different
afi/safi pairs in the same session and then ask ourselfs what having
indepent notifications/up events will buy you.

I can come up w/ 2 simple scenarios:
a) you want fate sharing... i.e. intentionally tie afis so that when
one fails the other does fail also. (both are required to provide a
service for instance).
b) you don't want to deal w/ the extra complexity of monitoring
multiple substates and prefer to deal w/ a binary "works" / "broken".

In both these examples which i consider rather realistic adding
notifications/negotiation does not provide value.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 26 Apr 2004 17:37:52 -0700 (PDT)

Pedro.

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 18:16:32 -0700

> working w/ all the functionality that has been configured on it, or

This is an implementation-specific design choice.

> nlri... in fact it allows you to control exactly what granularity is

Exactly. It also does not mean that it always mandates running one
afi/safi per session, which brings us back to today's BGP spec. So
lets just talk about that.

> and why would you do that *and* want per nlri mgmt of the session ???

Soft-notify does not need per-nlri "session"management. Whatever management
is needed - the state-machine and infra for that already exists post-
MP_REACH. Unless some implementation has limittaions, in which case it is
for that implementation to fix.

> chalenge to add this per nlri up/down negotiation.

I dont see any per nlri negotiation challenges. The mechanism exists
today and it works.

> of fault containment that works across all reasons for session

For session-failures yes. But theer are errors such as CEASE which
should not require a session-failure as they are independent of that.

> indepent notifications/up events will buy you.

Reduced #sessions, avoid session reestab latency (we are after all limited
by the speed of light :)), reduced overhead in terms of resources that
need to be allocated per-session and so on..

> notifications/negotiation does not provide value.

Give me one Provider who says that because IPv4 Unicast in their network
is needed for providing some IPv4 Multicast service, IPv4 unicast should
fail whenever IPv4 Multicast has an error or a CEASE notification.

I dont think these are realistic scenarios. However, thank you for your
opinion.

-Gargi

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 26 Apr 2004 18:16:32 -0700

-Gargi

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Apr 2004 00:25:20 -0700

All,

> chalenge to add this per nlri up/down negotiation.

Yes I agree that soft notify adds a new layer of troubleshooting & 
deployment complexity. While today most of the monitoring tools or SNMP 
work on a per session granularity it would require to be immediately 
updated to go deeper to the AFI/SAFI per session levels. Otherwise 
operators may have a really hard time to monitor what is going on. And 
unless they know that one AFI/SAFI is down under a working BGP session 
their NOC can't log in and fix the problem hence end customers may be 
impacted. Maybe it goes without saying that modifications to a number of 
show commands would be also required.

On the other hand what is not clear to me is why do we equate 
Soft-Notify to address just the session reset piece. For whatever it is 
worth my observations of various BGP deployments today lead me to 
believe that BGP code in most implementations does not trigger session 
Notifications in the first place that often ;). So I am not sure if we 
are solving a real problem here. And the problem at hand should be 
solved with the simplest solution so multisession seems to fit the bill. 
Moreover multisession seems to be an automation to today's manual 
session separation which some operators are already using.

That said I think one could observe that Soft-Notify does not just 
address the reset problem. Well maybe the name of the draft is wrong :) 
The functionality I support in it is to inform the peer about some BGP 
actions or events without resetting the session. As original INFORM 
draft was proposing and very similar to what Enke's cease msg defines 
for the Notification itself.

Just an real live example ...

BGP draft says:

    A BGP speaker MAY support the ability to impose an (locally config-
    ured) upper bound on the number of address prefixes the speaker is
    willing to accept from a neighbor. When the upper bound is reached,
    the speaker (under control of local configuration) either (a) dis-
    cards new address prefixes from the neighbor (while maintaining BGP
    connection with the neighbor), or (b) terminates the BGP connection
    with the neighbor. If the BGP speaker decides to terminate its BGP
    connection with a neighbor because the number of address prefixes
    received from the neighbor exceeds the locally configured upper
    bound, then the speaker MUST send to the neighbor a NOTIFICATION mes-
    sage with the Error Code Cease. The speaker MAY also log this
    locally.

So in the case operator choose to select option (a) above his EBGP peer 
has no way of knowing about action of his peer.

So maybe a good approach would be to reword the draft to primarily 
deliver the BGP event messaging between peers not causing the session 
resets while still allowing an optional vendor specific pool of msg types.

Therefor market and operators could decide which messages/actions are 
useful and which not ... In that light I would support to accept the 
reworded draft as an IDR WG doc.

R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Apr 2004 00:25:20 -0700

All,

BGP draft says:

R.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Apr 2004 13:16:34 +0300 (EEST)

> fail whenever IPv4 Multicast has an error or a CEASE notification.

And when would such an error occur?  If you have shared 
unicast/multicast infrastructure, pretty much never, unless both would 
be equally impacted.   And when the topologies aren't congruent, then 
you will notice it in any case.

I share Pedro's concerns about the applicability.  If operators see it
important to protect AFI/SAFIs from each other, something like
"multisession" seems like an obvious choice.  If there is an obvious
choice, it will be deployed as well.

It seems like we're talking about a solution which would become 
interesting either in the scenario where 1) operator is not 
(sufficiently interested) for doing something like multi-session BGP 
(but could be interested in something like this), or 2) operator 
doesn't want to wait for multi-session, and wants something sooner.

Both of these scenarios seem very questionable to me.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Apr 2004 13:16:34 +0300 (EEST)

---

From: Parantap Lahiri <[email-masked]>
Date: Wed, 28 Apr 2004 11:54:48 -0400

The response to this particular thread has been particularly interesting. 

So long the dominant story from this community has been to put all new
services and new features on the existing BGP protocol, which has an
established base, and keep the operator's world easy and simple. The
argument was that the vendors were good enough to handle all the
complexities in the protocol implementation and the operators need not worry
about code issues as much. So the (over)loading of BGP continues. Some
people, realizing that the BGP train was coming too fast and too strong,
stopped arguing.

Now, here is this thread, where a part of the same community is suggesting
that giving individual soft control to each AFI/SAFI pair would make BGP
protocol implementation more complicated than necessary and we should push
the complexity to the operator world. That is fine and in some ways sane,
but in most ways confusing. 

If the community has already made its mind that BGP is going to carry most
of the services, the vendor community has accepted to undertake that
incremental complexity and the operators have accepted to live with the
risk, then resisting this draft from going to WG, is a mixed signal. If
everyone HAS to live with multiple AFI/SAFI in the same session, they might
as well get their control and not think about how many sets of sessions they
should run in their infrastructure.

If the BGP session has to be split it should be split across the
infrastructure and service boundary. The infrastructure layer should run
hardened well tested BGP code and the service layer could run new loaded BGP
(or ??) code which will have individual control of individual services
built-in.

-Parantap

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pekka
Savola
Sent: Tuesday, April 27, 2004 6:17 AM
To: Gargi Nalawade
Cc: Pedro Roque Marques; [email-masked]; Yakov Rekhter
Subject: Re: [Idr] Soft-Notify as an IDR WG document

---

From: Parantap Lahiri <[email-masked]>
Date: Wed, 28 Apr 2004 11:54:48 -0400

-Parantap

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 28 Apr 2004 09:46:14 -0700 (PDT)

Parantap Lahiri writes:

> Now, here is this thread, where a part of the same community is
> suggesting that giving individual soft control to each AFI/SAFI pair
> would make BGP protocol implementation more complicated than
> necessary and we should push the complexity to the operator
> world. That is fine and in some ways sane, but in most ways
> confusing.

This is a misrepresentation of the argument.

The point is that you cannot achieve individual control for afi/safi
without adding the necessary diagnostics and support for tools and
management on the operator side. Not to mention understanding of how
mecanisms work.

The multisession draft is nicer alternative for several reasons
including the fact that it fits into the current management framework
and follows a model understood by all.

The point is not wether to achieve a given end goal but to find the
approach that gets us there with less pain. and which can be built
incrementally. 

As an operator i would expect you to be supportive of the need to
consider the network management implications before picking a
solution.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 28 Apr 2004 09:46:14 -0700 (PDT)

Pedro.

---

From: Parantap Lahiri <[email-masked]>
Date: Wed, 28 Apr 2004 17:29:01 -0400

I am not sure if it was a complete misrepresentation of your argument. You
do mention in your mail that 

>> Besides multisession is 10x easier to implement and deploy since it can
use existing state machines.

As an operator we definitely do keep network management implications in our
mind while choosing any mechanism and I appreciate your concern there. And
the fact that adding BGP complexity is worrying some is a good sign. 

Though whatever choice you make has tactical as well as strategic
implications. BGP is becoming a generic protocol to transport not only
routing but also service information. Now the question is whether to control
these information flows at a higher AFI/SAFI level or to split them apart
and tie them down to lower tcp session level? Definitely the operators are
familiar with managing BGP TCP sessions, but if you are too quick to arrive
at the latter alternative and discard the former one for lack of NMS
functions you may run the risk of not assigning the right function to the
right component. I have no idea how the number of AFI/SAFI and their
functions there-of are going to evolve in future, but if we start bundling
them together in subsets and tie the control mechanisms of each subset to a
tcp session, it has to be more conscious and well thought decision than a
quick tactical one depending on short-term merit.

I will be interested in understanding how multisession BGP stacks up with
running completely separate BGP between the same end points. [I understand
that its not doable now, but just trying to gauge the merit]

-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 12:46 PM
To: Parantap Lahiri
Cc: [email-masked]; 'Yakov Rekhter'
Subject: RE: [Idr] Soft-Notify as an IDR WG document

  Pedro.

---

From: Parantap Lahiri <[email-masked]>
Date: Wed, 28 Apr 2004 17:29:01 -0400

-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 12:46 PM
To: Parantap Lahiri
Cc: [email-masked]; 'Yakov Rekhter'
Subject: RE: [Idr] Soft-Notify as an IDR WG document

  Pedro.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 18:22:43 +0300 (EEST)

> should run in their infrastructure.

Why would anyone want have to live with multiple AFI/SAFI in the same
session if (s)he could set them up as separate sessions?

It seems that soft-notify accomplishes a subset of goals which 
multisession (and the like accomplish), but with a lot of additional 
issues.  The implementation or deployment complexity is probably 
roughly equal.  

So, this makes me wonder why soft-notify should go forward here at
all?

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 18:22:43 +0300 (EEST)

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 30 Apr 2004 17:04:44 -0400

> Please comment on the attached. The deadline for comments is

I would urge that this document not be accepted.  I think that
a multi-session BGP is a better solution, perhaps with a graceful
failover mechanism.  I would offer many of the same reasons that Pedro
did, specifically the inability to deal with a corrupt TCP stream.

I believe that most of the shutdown reasons that we cared about have
been addressed in the current cease subcode document undergoing last call.

The prefix-limit issue is working itself out in other documents.

One note on BGP multi-session with regards to operational issues:
The BGP v2MIB includes the ability to montior multiple peering
sessions to a single peer across the same src/dst addresses.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 30 Apr 2004 17:04:44 -0400

-- 
Jeff Haas 
NextHop Technologies