Subject: [Idr] Fwd: New Version Notification for draft-varlashkin-idr-multisession-same-port-00

From: Ilya Varlashkin <[email-masked]>
Date: Fri, 9 Apr 2010 19:12:06 +0200

Hi,

I've summed up my thoughts on implementing BGP multisession without introduction of new TCP ports to the protocol and posted them as a draft (http://tools.ietf.org/html/draft-varlashkin-idr-multisession-same-port-00). I'd like to ask group's comments and opinion on approach described in the draft.

P.S.: it's my first draft submission and english isn't my native language, so please don't shoot me if there are some mistakes

Kind regards,
iLya

> From: IETF I-D Submission Tool <[email-masked]>
> Date: April 9, 2010 6:46:08 PM GMT+02:00
> To: [email-masked]
> Subject: New Version Notification for draft-varlashkin-idr-multisession-same-port-00 
> 
> 
> A new version of I-D, draft-varlashkin-idr-multisession-same-port-00.txt has been successfully submitted by Ilya Varlashkin and posted to the IETF repository.
> 
> Filename:	 draft-varlashkin-idr-multisession-same-port
> Revision:	 00
> Title:		 Multisession BGP extensions without new TCP ports
> Creation_date:	 2010-04-09
> WG ID:		 Independent Submission
> Number_of_pages: 10
> 
> Abstract:
> This document proposes minor backward-compatible changes to BGP for
> enabling multiple sessions to be established between pair of BGP
> speakers for different AFI/SAFI or groups of thereof.  It also
> describes mechanism for handling each session in separate process
> (for information only).  This memo updates BGP and multiprotocol
> extensions for BGP-4 specifications .
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 16 Apr 2010 14:24:19 +0200 (CEST)

On Fri, 9 Apr 2010, Ilya Varlashkin wrote:

> I've summed up my thoughts on implementing BGP multisession without 
> introduction of new TCP ports to the protocol and posted them as a draft 
> (http://tools.ietf.org/html/draft-varlashkin-idr-multisession-same-port-00). 
> I'd like to ask group's comments and opinion on approach described in 
> the draft.

Without knowing a lot of any underlying problem that might exist, 
Ioperationally like the idea of not adding more ports to BGP for reason of 
control plane protection, filtering and other similar mechanisms that use 
the port as an identifier.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Dominik Bay <[email-masked]>
Date: Fri, 16 Apr 2010 14:54:31 +0200

On Fri, 16 Apr 2010 14:24:19 +0200 (CEST)
Mikael Abrahamsson <[email-masked]> wrote:

> > I'd like to ask group's comments and opinion on approach described
> > in the draft.
> 
> Ioperationally like the idea of not adding more ports to BGP for
> reason of control plane protection, filtering and other similar
> mechanisms that use the port as an identifier.

I fully agree with Mikael here. From the overhead adding this
feature described in Ilyas draft it is clearly operation-friendly and
does not have anything probably harmful like adding additional ports to
filters in it. It also has a nice way for backwards compatibility.

-- 
Kind regards,
Dominik Bay

---

From: jim deleskie <[email-masked]>
Date: Fri, 16 Apr 2010 13:06:02 -0300

I also support the idea of letting BGP do the heavy lifting without
the need for extra ports.  The need to not add operational complexity
should always be the primary goal.

On Fri, Apr 16, 2010 at 9:54 AM, Dominik Bay
<[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 17 Apr 2010 00:06:37 +0200

Hi Jim,

> the need for extra ports.The need to not add operational complexity

I think we indeed should take into consideration amount of operational 
complexity involved here. With Ilya's proposal the issue of mapping 
instances of BGP to be handled by particular SAFIs is not going to 
disappear see section 8 "AFI/SAFI grouping".

Instead pre-allocating one new well know port like described in ti-bgp 
proposal to carry non routing related information separately from 
Internet routes or instead of session separation between SAFIs each 
running on new dynamic port like described in multisession proposal - 
this draft requires manual mapping in each router to what set of SAFIs 
is handed over to which BGP instance.

And for this to make any real sense in the entire scope of given 
AFI/SAFI coverage one need to be able to manually be in sync in 
configuration not only intra-domain, but also on inter-as boundaries. 
Especially considering the latter I find it quite operationally complex 
exercise if not at all unrealistic in practice.

So to summarize IMHO it really seems much simpler to add one new well 
know port into filters then try to manually correlate SAFIs to BGP 
instances at each hop especially considering required correlation 
between BGP domains each running various routing operating systems.

Cheers,
R.

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 19 Apr 2010 09:07:18 +0200

> -----Original Message-----
> Hi Jim,
> 
> I think we indeed should take into consideration amount of 
> operational complexity involved here. With Ilya's proposal 
> the issue of mapping instances of BGP to be handled by 
> particular SAFIs is not going to disappear see section 8 
> "AFI/SAFI grouping".
> 

Robert,

this is not the message I tried to communicate in section 8 :-) My
intention was to show that hardcoding (==defining at code time) AFI/SAFI
groups is not a good idea, and instead it should be left for
configuration time. If we don't impose restrictions on which session
should carry particular AFI/SAFI then there is no mapping issue.

> Instead pre-allocating one new well know port like described 
> in ti-bgp proposal to carry non routing related information 
> separately from Internet routes or instead of session 
> separation between SAFIs each running on new dynamic port 
> like described in multisession proposal - this draft requires 
> manual mapping in each router to what set of SAFIs is handed 
> over to which BGP instance.
> 
This approach seems to be inflexible. Today an operator may want to
separate one set of AFI/SAFI into dedicated session, tomorrow's needs
may be different. Besides, some implementations may find one set of
AFI/SAFI more suitable for grouping (e.g. to optimise implementation),
while other will want to have different set of AFI/SAFI in a group (for
the same reason). My draft proposes neutral approach - don't impose hard
grouping, if you do, at least allow trivial groups (single AFI/SAFI per
session) as common denominator.

> And for this to make any real sense in the entire scope of 
> given AFI/SAFI coverage one need to be able to manually be in 
> sync in configuration not only intra-domain, but also on 
> inter-as boundaries. 
> Especially considering the latter I find it quite 
> operationally complex exercise if not at all unrealistic in practice.
> 
On contrary, this looks like one of the operational parameters two
network operators will agree upon when establishing peering. And if
things go amiss (e.g. due to a bug), operators can quickly move
offending AFI/SAFI to dedicated session. That's flexibility from my
(operator's) PoV.

> So to summarize IMHO it really seems much simpler to add one 
> new well know port into filters then try to manually 
> correlate SAFIs to BGP instances at each hop especially 
> considering required correlation between BGP domains each 
> running various routing operating systems.
>
I don't rule out that this may be simpler from implementor's PoV. But
for operators that's not necessary the case. Would be nice to hear
other's opinion on the subject.

Cheers,
iLya

---

From: Kristian Larsson <[email-masked]>
Date: Mon, 19 Apr 2010 11:30:05 +0200

+1

  -K

On Fri, Apr 16, 2010 at 02:24:19PM +0200, Mikael Abrahamsson wrote:
>> I'd like to ask group's comments and opinion on approach described in the 
>> draft.
> 

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511			              [email-masked]