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

[Pierre Francois <[e-mail]>]

Robert, 

On Aug 5, 2013, at 11:47 AM, Robert Raszuk <[e-mail]> wrote:

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

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 :)


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

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.


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

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

Cheers,


Pierre.

> 
> Best regards,
> R.
> 
> 
> On Mon, Aug 5, 2013 at 10:59 AM, Pierre Francois
> <[e-mail]> wrote:
>> 
>> 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* :)
>> 
>> 
>> On Aug 3, 2013, at 11:44 AM, Robert Raszuk <[e-mail]> wrote:
>> 
>>> 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.
>>> 
>>> 
>>> On Fri, Aug 2, 2013 at 11:31 AM, Saikat Ray (sairay) <[e-mail]> wrote:
>>>> 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.
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>