Subject: [Idr] I-D Action:draft-ietf-idr-bgp-multisession-05.txt

From: [email-masked]
Date: Tue, 23 Mar 2010 10:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Multisession BGP
	Author(s)       : J. Scudder, C. Appanna
	Filename        : draft-ietf-idr-bgp-multisession-05.txt
	Pages           : 16
	Date            : 2010-03-23

This specification augments "Multiprotocol Extensions for BGP-4" (MP-
BGP) by proposing a mechanism to facilitate the use of multiple
sessions between a given pair of BGP speakers.  Each session is used
to transport routes related by some session-based attribute such as
AFI/SAFI.  This provides an alternative to the MP-BGP approach of
multiplexing all routes onto a single connection.

Use of this approach is expected to provide finer-grained fault
management and isolation as the BGP protocol is used to support more
and more diverse services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-05.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.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 23 Mar 2010 11:28:35 -0700

FYI this is just a version bump, no substantive changes vs. -04.

--John

On Mar 23, 2010, at 10:45 AM, [email-masked] wrote:

> <draft-ietf-idr-bgp-multisession-05.url>_______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 24 Mar 2010 09:55:13 +0100

> > ftp://ftp.ietf.org/internet-drafts/

I read this draft and while I like the idea to have the possiblility to
have multiple sessions open between two peers I do not understand why a
port redirection had to be added to this draft.  There is no reason to
have a mechanism to redirect BGP sessions.  On the other hand security
implications created by this redirection mechanism are severe.
Why do all implementations need to suffer because of this?  Multisession
BGP can work perfectly well without the added port redirection.

regards
-- 
Claudio Jeker
OpenBGPD developer

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Wed, 24 Mar 2010 10:52:26 +0100

John,

during the meeting in Stockholm (as recorded in "minutes") and later in
private mail discussion with you I've already pointed out that
multi-session can be implemented without need for new (even dynamic) BGP
ports. A mechanism exists for many modern operating systems, including
those used as foundation for routers' software, that allows handover of
already-established connections to already-running process that may or
may not be a child process of the one that has initially handled the
connection. Due to this implementation of per-AFI/SAFI or per-group
session in separate process becomes local matter and does not require
protocol extention. My concern as of a network operator is unnecessary
protocol complexity.

You have mention that there may be scenarios where extra port is
required, but without providing details to back the statement. Based on
available information the draft does not add extra functionality that
could not be implemented with existing protocol, but it adds complexity.
So currently I believe it's in the interesty of the Internet community
at large to avoid extending BGP until there is more clear evidence that
such extention is absolutely necessary. This is also in line with IETF
spirit/motto that existing stuff should be reused and things should not
be added just for the sake of being added.

Hope the WG supports this view. If necessary I could elaborate on
specific points.

Kind regards,
iLya

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 24 Mar 2010 08:59:23 -0700

Ilya (also Claudio),

I should have added in my message that I do owe a substantive update and that an -06 will be forthcoming which I think will address your issues.  The -05 bump was just to keep the document fresh in the mean time.  Thanks for your comments and reminder.

Regards,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Mar 2010 14:55:40 -0700

Hi Ilya,

I agree with you that it is possible today to perform a session handover 
of established connections between running processes.

The thing which is missing is a standard based interoperable way to 
signal between BGP instances under which process given BGP AFI/SAFI 
should be homed.

My transport instance draft essentially addresses only this by proposing 
definition of a new port number in fact making things much simpler and 
avoiding even the need for such handover.

Many thx,
R.

> _______________________________________________
> Idr mailing list
> [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Mar 2010 14:55:43 -0700

Hi John,

I also think that we do not have any substantive evidence that we need 
to add complication to BGP OPEN behavior going that far as dynamic port 
redirection allowing for arbitrary number of BGP sessions to get created 
each set of them binded to a different port then served by different BGP 
instance.

Looking at real network practical requirements (just like it was 
proposed in link state IGPs) there is a simple need to separate routing 
from non-routing information when carried in BGP.

That is why I proposed a very simple decoupling based on a new BGP port 
number for transport instance BGP.

https://datatracker.ietf.org/doc/draft-raszuk-ti-bgp/

Just posted the -01 version with only date and version adjustment.

Cheers,
R.

> Ilya (also Claudio),
>
> I should have added in my message that I do owe a substantive update
> and that an -06 will be forthcoming which I think will address your
> issues.  The -05 bump was just to keep the document fresh in the mean
> time.  Thanks for your comments and reminder.
>
> Regards,
>
> --John

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 25 Mar 2010 08:27:17 +0100

> -----Original Message-----
> Hi Ilya,
> 
> I agree with you that it is possible today to perform a 
> session handover of established connections between running processes.
> 
> The thing which is missing is a standard based interoperable 
> way to signal between BGP instances under which process given 
> BGP AFI/SAFI should be homed.
> 

Isn't this already in the protocol? When a new BGP session comes up the
routers announce to each other which AFI/SAFI the session carries. Once
master process figures out which AFI/SAFI related to given session it
can handover the connection to another process using locally-appropriate
method of which peer doesn't have to know. 

What needs to be revisited is collision handling. Currently if there is
already established session between two routers and one of them attempts
to establish new session, then one of the sessions will have to be
closed. For multisession mechanism to work we need to ammend session
collision handling so that it applies only when AFI/SAFI of the existing
and new sessions match or overlap (I haven't thought yet what's better),
but when two sessions have non-overlapping set of AFI/SAFI then it's up
to implementation to handle it within same or different process.

/iLya

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Mar 2010 01:05:34 -0700

Hi Ilya,

> method of which peer doesn't have to know.

The point I am trying to suggest is to relax the need for such master 
process (single point of failure) to exists. This also would remove the 
need for session handover which some older operating systems may have a 
real problem with.

> closed.

Well I have tested three BGP commercial implementations and non of them 
checks new BGP OPEN router_id with the existing sessions of the same 
router_id. So for all practical purposes there is no issue there.

> For multisession mechanism to work we need to ammend session

I really don't think that different process per each SAFI is required. 
As far as multisession I can count on one hand folks who really tried 
it. As it stands today it is already quite a stretch for operators to 
deploy it. If we move it to -06 with dynamic port negotiation even if 
knobbed I bet it will not make it easier and simpler to use.

 > but when two sessions have non-overlapping set of AFI/SAFI then it's
 > up to implementation to handle it within same or different process.

What you said is the real concern I have with this approach. If we allow 
each implementation to make it's own decision on how to handle a SAFI 
then we will likely have a zoo of choices with the end result being 
rather poor. The real idea is for a new SAFI to be able to tell in the 
spec if it should be carried in internet instance or transport instance. 
Please notice that even if one router in the path mixes the choice or 
just does not support handover any instability in any existing SAFI will 
be reflected across all SAFIs and will defeat the purpose of the entire 
exercise.

Cheers,
R.

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 25 Mar 2010 09:59:26 +0100

> > Once master process figures out which AFI/SAFI related to given 
> > session it can handover the connection to another process using 
> > locally-appropriate method of which peer doesn't have to know.
> 
> The point I am trying to suggest is to relax the need for 
> such master process (single point of failure) to exists. This 
> also would remove the need for session handover which some 
> older operating systems may have a real problem with.
> 
But your proposal introduces new static TCP port(s) which is inflexible
with respect to number of AFI/SAFI and undesirable from operational
prospective (IDS, firewalls/filters, traffic capturing). As for master
process - inetd has 

> Well I have tested three BGP commercial implementations and 
> non of them checks new BGP OPEN router_id with the existing 
> sessions of the same router_id. So for all practical purposes 
> there is no issue there.
> 
You mean that they allow you to establish two sessions? I suspected so
much :-) It just means that implementations are not conformant to
section 6.8 of RFC4271. But if somebody comes up with compliant
implementation, then things will get hairy. If the behaviour you
observed is de facto standard, then we need to modify protocol
specification to reflect the reality.

> > For multisession mechanism to work we need to ammend 
> session collision 
> > handling so that it applies only when AFI/SAFI of the 
> existing and new 
> > sessions match or overlap (I haven't thought yet what's better),
> 

It doesn't need to be "required". But why not allow decision to be made
at run time rather than hardcoded during implementation? If things go
amiss, operator could move offending AFI/SAFI to a separate process.

> As far as multisession I can count on one hand folks who 
> really tried it. As it stands today it is already quite a 
> stretch for operators to deploy it. If we move it to -06 with 
> dynamic port negotiation even if knobbed I bet it will not 
> make it easier and simpler to use.
> 
I'm not in favor of adding any new ports to BGP, neither static nor
dynamic.

> What you said is the real concern I have with this approach. 
> If we allow each implementation to make it's own decision on 
> how to handle a SAFI then we will likely have a zoo of 
> choices with the end result being rather poor. The real idea 

Not implementations, but operators should decide how to shuffle AFI/SAFI
around (possibly involving close cooperation with the vendors). There
must be some guidelines for operators how and when to assign AFI/SAFI to
various processes, and implementations must be flexible enough to allow
this. If _protocol_ depends on whether it's implemented in one or N
processes, then something is wrong I believe. In my opinion from
protocol prospective implementation should be allowed to be a black-box
- whatever happens inside is irrelevant as long as it looks like
protocol X to outside world.

/iLya

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 25 Mar 2010 10:00:22 -0700

> to implementation to handle it within same or different process.

FYI this is basically what 5.1.3 of the multisession draft says.  (The "overlap" variant.)

--John