Subject: [Idr] BGP Path Marking comments for IETF 87 session

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 Aug 2013 10:13:42 -0400

The microphone comment was going to be brief:
BGP churns a bunch already.
This feature will add churn to routes.

Why is this marking helpful enough to override churn considerations?

-- Jeff

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Fri, 2 Aug 2013 09:31:48 +0000

As the draft says, no additional advertisements should be done just to send the extcomm. I.e., the path is advertised only if the path would have been advertised anyway (due to other reasons), and you tack on the extcomm.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, August 01, 2013 7:14 AM
To: [email-masked]
Subject: [Idr] BGP Path Marking comments for IETF 87 session

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 3 Aug 2013 11:44:46 +0200

Saikat,

As we have discussed after the meeting while I am not worried about
churn that much - as  churn may mostly be in the case of add-paths I
am concerned that the consequence of this marking is intended to have
direct impact on best path selection algorithm of BGP speakers.

In IDR we have decided few meetings back that we should group all
proposals which tent to impact best path selection under common
umbrella and stop proposing point solutions which do punch more holes
in the best path algorithm. That applies equally to multipath
selection as well.

One protocol which is designed to be universal solution for this is
cost community draft. Sure additional POIs may be needed or it may
need to be explicitly extended to also play active role in not only
best path selection, but also multipath selection. For your
application (which is for some reasons ability not to select best
external as multipath candidate) it seems the pre-best path POI of
cost community will work just fine today.

If we add now a lot of new colors yet not clearly spell out their
impact to local best path selection rules leaving this just for the
configuration policy the result especially in IBGP networks may be
rather poor.

So I suggest we first wait for general WG consensus on how much we
should continue to create more wholes in the best path selection and
once we reach consensus that this is required we generalize the
mechanism for it via standards track.

Best regards,
R.

---

From: Pierre Francois <[email-masked]>
Date: Mon, 5 Aug 2013 10:59:48 +0200

Robert, all

Thank you for your feedback. 

I went at the mic a few IETF meetings back in order to ask the audience about how to describe the status of paths, because
making the assumption that a received path was installed is no longer valid. I have asked if I'd tag paths or use BMP.
I have been told by multiple people, notably at the mic, that BGP was the best place to talk about BGP paths, which makes sense to me.

Even if we'd delay the support of impacting the BGP decision process based on the properties of the paths defined by these flags, 
we need the flags for the monitoring purposes described in the doc. They are the initial motive of the draft. Currently if you try to cross-correlate
netflow data with BGP routes that you collect by establishing iBGP sessions with your routers, you have to run error-prone off-line simulation in order to know who selected what and your traffic analysis is "subject to the accuracy of your model".

So what do we do, we cut the part from the draft that says the flags are also needed to impact the decision process and we re-meet in Vancouver?

Cheers,

Pierre.

PS: If  it has been decided a few IETF meetings back to delay X in order to have it done neatly, then maybe we should actually do X *now* :)

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 5 Aug 2013 11:47:52 +0200

Hi Pierre,

Well for monitoring purposes I have heard from many Internet
researchers that we need not only know about current status of the
path, but also we need to know why given BGP implementation and in
particular which bgp best path selection algorithm step has determined
such path status.

Brute force way is to create your own BGP abstraction layer of a
network and feed it with MRT input streams of your EBGP sessions. BMP
could also be used if you are ok with all inbound drops or don't care
about malformed updates etc ...

But if we are to mark paths and if the objective is to influence best
path or multipath selection rules I think it makes sense to try to
generalize this a bit.

Best regards,
R.

---

From: Pierre Francois <[email-masked]>
Date: Mon, 5 Aug 2013 12:30:36 +0200

Robert, 

> particular which bgp best path selection algorithm step has determined

It was not part of what I was asked to provide, but I am obviously open to discuss this. 
I had been asked to keep things simple, just compensating for what we had lost with the introduction of best-external and add-paths: 
i.e., "is this path selected as best". I can always add complexity but I'd like to be requested for it :)

> network and feed it with MRT input streams of your EBGP sessions.

Yes, the modelling approach.  It is very complicated to make it accurate in practice...

> BMP could also be used if you are ok with all inbound drops or don't care
> about malformed updates etc …

This I had asked at the IDR session of Atlanta, and I had been told by two multiple BMP people it was hard to do the marking there because
that would turn the code into a spaghetti, as the best path selection process is not happening where BMP is.

> path or multipath selection rules I think it makes sense to try to

Fine with me, let me check with all the co-authors. 

Cheers,

Pierre.