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

[Pierre Francois <[e-mail]>]

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