Subject: [Idr] RFC5065 - Section 5.3

From: David Freedman <[email-masked]>
Date: Tue, 08 Jul 2008 14:44:21 +0100

Admittedly I'm a little late for this now that draft-ietf-idr-rfc3065bis
is now an RFC, but I'm unclear as to why Section 5.3 (3) states:

3) When comparing routes using AS_PATH length, CONFED_SEQUENCE and
      CONFED_SETs SHOULD NOT be counted.

I would rather have said:

When comparing routes using AS_PATH length, an implementation MAY
provide the ability to count CONFED_SEQUENCE and CONFED_SET.

Looking back through the archives, I see Ilya Varlashkin has commented
on this previously :

(http://www.nabble.com/BGP-best-path-selection-in-confederations-(draft-ietf-idr-rfc3065bis-06.txt)-td11081109.html#a11081109)

I too run a network where each subconfederation has a discrete IGP and I
do not wish them to interact, an implementation which provides the
ability to count CONFED_SEQUENCE / CONFED_SET and use this for route
comparison would be extremely useful, I do not understand why the
author(s) have used "SHOULD NOT" in this case, it seems silly.

Can somebody explain?

Regards,

David Freedman

- --
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Jul 2008 09:58:20 -0400

David,

Some of this is my opinion and some my recollection of the events at the
time.  Your mileage may vary.

> Looking back through the archives, I see Ilya Varlashkin has commented

And a few other people, including me.

There is nothing stopping a vendor from providing a knob to accomplish
this very feature.  However, as with everything else regarding BGP path
selection, the important thing is that route selection is done
consistently AS-wide.  As long as that is the case, you can do pretty
much anything you like.

The more widely deployed implementations of BGP ignored confederation
segment length as part of its route selection by default.  Thus this
became somewhat a matter of doing what the big vendors did.

The language thus was written to heavily favor interoperability over
flexibility.  This avoids having to discuss the picky issues of
consistent route selection across the AS within a specific extension.

-- Jeff

---

From: David Freedman <[email-masked]>
Date: Tue, 08 Jul 2008 15:25:29 +0100

> this very feature.  

Other than the RFC is now explicit about this behaviour (where RFC3065
was not previously).

> consistent route selection across the AS within a specific extension.

Thanks, I do indeed understand but believe it makes it harder now to
convince vendors to "enhance" implementations now that there is an
explicit "SHOULD NOT"

Dave.

- --
David Freedman

---

From: Danny McPherson <[email-masked]>
Date: Tue, 8 Jul 2008 10:15:54 -0600

> convince vendors to "enhance" implementations now that there is an

It says "SHOULD NOT", not "MUST NOT".  This was done
for interoperability reasons.

Just a reminder, RFC 2119:
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the  
definition is an absolute prohibition of the specification.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that  
there may exist valid reasons in particular circumstances when the  
particular behavior is acceptable or even useful, but the full  
implications should be understood and the case carefully weighed  
before implementing any behavior described with this label.
Given BGP's deployment footprint and the path selection
criteria of existing routers, and the probability of introducing
routing stability with changes of this sort, this text still seems
prudent, IMO.

That said, given that even route reflection CLUSTER_LIST
lengths are considered in path selection, I do consider this
to be a reasonable request, convince your vendor(s) to do it,
the specification certainly doesn't prohibit it.

-danny

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Jul 2008 11:04:41 -0400

In message <[email-masked]>
> Other than the RFC is now explicit about this behaviour (where RFC3065

That is the difference between SHOULD NOT and MUST NOT.  The RFC says
SHOULD NOT.

> convince vendors to "enhance" implementations now that there is an

That hasn't been the case in the past.  It only dictates the default
setting of the control knob.  It will depend on the vendor clue level.

Curtis