Subject: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 13 Jun 2016 06:28:09 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-idr-ix-bgp-route-server-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Quick question: Why is the following statement a SHOULD and not a MUST:
"the route server SHOULD NOT prepend its own AS number to the AS_PATH
   segment nor modify the AS_PATH segment in any other way. "
Is this because the clients might eitherwise not accept the message? 
Maybe add one sentence to explain the SHOULD!

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 13 Jun 2016 14:42:17 +0100

> Maybe add one sentence to explain the SHOULD!

Hi Mirja,

This was the subject of some discussion recently on IDR.  Yes, probably
appropriate to add in a one-liner to explain why it's SHOULD rather than
MUST.

Nick

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 13 Jun 2016 16:17:49 +0200

Great! Thanks!

> Am 13.06.2016 um 15:42 schrieb Nick Hilliard <[email-masked]>:
> 
> Mirja Kuehlewind wrote:

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 13 Jun 2016 22:35:00 +0100

this is now changed as follows:

> https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508

Nick

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Jun 2016 11:34:22 +0900

> https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508

i hate to be old fashioned; actually, that's a lie; but is there either
an OLD/NEW here or an internet-draft.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 13 Jun 2016 22:36:49 -0400

> an OLD/NEW here or an internet-draft.

​did you mean: "Where is the full draft?"

​
https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/blob/5fd0508b617696ee2e60f9d9a6572d8682568d07/draft-ietf-idr-ix-bgp-route-server.xml

is the xml version at least... (there was a 'view' button that got me that
link)

it'd be rad if there was an auto-generation of the html/txt/(pdf?) versions
based on git commit hookage/etc.

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

---

From: "Randy Bush" <[email-masked]>
Date: Tue, 14 Jun 2016 11:38:38 +0900

> ​did you mean: "Where is the full draft?"

no.  i mean a real internet-draft, in the ietf drafts directory which i 
mirror.

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 13 Jun 2016 22:48:38 -0400

> no.  i mean a real internet-draft, in the ietf drafts directory which i

​oh! "hey, cool code kid, got an email to the submission bot to get your
changes to where we can all see them?" (version of: ​
http://static.flickr.com/87/240803829_9212773615_o.png)

err, maybe nick was thinking there might be more revisions on his text
options?

I'm not a native bgp speaker, but I'd question (for instance) the use of
'AS_PATH segment' in this part of the draft, given:

            "AS_PATH is a well-known mandatory attribute that is composed
            of a sequence of AS path segments.  Each AS path segment is
            represented by a triple <path segment type, path segment
            length, path segment value>."

from: https://tools.ietf.org/html/rfc4271

I would have thought 'segment' was an individual 'asn' (the triple I
suppose, the TLV) in the AS_PATH, not the whole 'AS_PATH' attribute. Maybe
instead of 'AS_PATH segment' in nick's revision:

             "This differs from the behaviour
              specified in section 5.1.2 of <xref target="RFC4271" />, which
              requires that the BGP speaker prepends its own AS number as
              the last element of the AS_PATH.  While it is technically
              possible to operate a route server which prepends its own AS
to
              the AS_PATH, it is not recommended to do so because this
              may adversely affect the resulting network topology between
the
              route server clients."

​again, I'm not a native bgp speaker, so I'm probably off base, but...
maybe there's a revision in the revision still to be had before updating
the actual draft archive?​

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Jun 2016 12:14:50 +0900

> err, maybe nick was thinking there might be more revisions on his text

see OLD/NEW comment above

>              "This differs from the behaviour specified in section
>               5.1.2 of <xref target="RFC4271" />, which requires that
>               the BGP speaker prepends its own AS number as the last
>               element of the AS_PATH.  While it is technically
>               possible to operate a route server which prepends its
>               own AS to the AS_PATH, it is not recommended to do so
>               because this may adversely affect the resulting network
>               topology between the route server clients."
> 

i think what might be said is "creating an undesirably longer AS_PATH"
and thus biasing receivers against using the exchange.

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Jun 2016 12:48:35 +0900

> and thus biasing receivers against using the exchange.

my bad (trans-pac and not enough coffee).  we're discussing the
opposite, why one might want the RS to have an AS in my path.  well, to
me it would be because i have one a path directly from peer and one via
the RS.  i would prefer the former.  see draft-ietf-idr-rs-bfd-01.txt
for why i kinda like to know layer two is up.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Jun 2016 06:25:56 +0200

Let's observe that nothing prevents such "one" to extend it's inbound
AS_PATH for nets he learns from RS with additional AS to make it less
preffered ... without any special action to be taken by RS itself.

Thx
R.

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Jun 2016 13:28:37 +0900

>> for why i kinda like to know layer two is up.

and the sender can prepend when sending to the RS.  and and and.  the
point is not to explore all possible hacks, but to explain why this
SHOULD is not a MUST.

life can be simple.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jun 2016 11:15:42 +0100

Christopher Morrow wrote:
> err, maybe nick was thinking there might be more revisions on his
> text options?

something like that.  Who was it who said that dealing with the IETF is
like being nibbled to death by ducks?

> I'm not a native bgp speaker, but I'd question (for instance) the use
> of 'AS_PATH segment' in this part of the draft, given:

> ​again, I'm not a native bgp speaker

No, you're correct.

> so I'm probably off base, but... maybe there's a revision in the
> revision still to be had before updating the actual draft archive?​

That would probably be tempting fate but then again, the reason the IETF
exists at all is because fate was tempted.  It would be a shame to lose
that spark.

> and thus biasing receivers against using the exchange.

"creating an undesirably longer AS_PATH" works, but "biasing receivers
against using the exchange" is language that I would prefer to avoid,
the reason being that route servers have an expected behaviour which is
to provide a comparable topology view to bilateral peering.  In this
regard, jamming the RS ASN into the path violates the principal of least
astonishment.  The art is to distil this sentiment into a single sentence.

The wording has been updated as follows:

github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/686ed8a

Is there consensus on this wording?  If so I'll post -12.

Nick

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Jun 2016 19:29:31 +0900

>> and thus biasing receivers against using the exchange.

and i recanted as it did not answer kühlewind's point

> github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/686ed8a

and therefore i do not that that does.

> segment nor modify the AS_PATH segment in any other way. "

i suggested an example; a corner case.  but corner cases are typical for
a MUST being a SHOULD

> we're discussing the opposite, why one might want the RS to have an AS
> in my path.  well, to me it would be because i have one path directly
> from peer and one via the RS.  i would prefer the former.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jun 2016 13:08:25 +0100

> i suggested an example; a corner case.  but corner cases are typical for

there are a bunch of corner cases associated with this particular situation.

Does the proposed wording work for you?

> While it is technically possible to operate a route server which
> prepends its own AS to the AS_PATH, it is not recommended to do so
> because creating an undesirably longer AS_PATH may adversely affect
> the resulting network topology between the route server clients.

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 14 Jun 2016 10:42:27 -0400

> Does the proposed wording work for you?
​lgtm, thanks!​

---

From: Randy Bush <[email-masked]>
Date: Wed, 15 Jun 2016 02:08:02 +0900

>> the resulting network topology between the route server clients.

i suspect that the AD is competent to speak for herself.  but imiho this
misses her point, why is the SHOULD not a MUST?  this says why it might
be a MUST.  why allow the loophole?  i admit my example was baroque.

randy

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 14 Jun 2016 23:19:20 -0500

Hi, Nick,

> https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508

I had the same question as Mirja, but balloted No Objection because the
discussion was already taking place in this thread.

I've looked at
https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508,
but I'm still confused.

The document defines a route server as "not a router", because it doesn't
forward packets - the text is

   Although a route server uses BGP to exchange reachability information
   with each of its clients, it does not forward traffic itself and is

   therefore not a router.

If the route server does prepend its own AS number to the AS_PATH, won't it
then receive packets that it can't forward?

Can you help me understand what I'm missing here?

Thanks!

Spencer

---

From: joel jaeggli <[email-masked]>
Date: Tue, 14 Jun 2016 21:29:16 -0700

On 6/14/16 9:19 PM, Spencer Dawkins at IETF wrote:
> Hi, Nick,
> 
> On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> The document defines a route server as "not a router", because it
> doesn't forward packets - the text is 
> 
> If the route server does prepend its own AS number to the AS_PATH, won't
> it then receive packets that it can't forward?

Nah, the AS path only counts for path selection. What matters as far as
forwarding goes is what the nexthop on the route is.

In a normally functioning exchange the routeserver will never set itself
to be the nexthop of a learned so the nexthop route will remain the
originator of the route which is another router on the same (connected)
subnet. Since the router(s) peering with the route-server all have the
subnet/netmask configured on their connected interface, they can resolve
all of the nexthops learned from the routeserver via arp.

> Can you help me understand what I'm missing here?

Probably that does it.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 15 Jun 2016 00:00:11 -0500

Joel,

On Tue, Jun 14, 2016 at 11:29 PM, joel jaeggli <[email-masked]> wrote:

> ,

Thanks - it does.

Spencer

---

From: Randy Bush <[email-masked]>
Date: Wed, 15 Jun 2016 16:13:07 +0900

> then receive packets that it can't forward?

AS numbers and AS_PATHs are not used for forwarding.

randy

---

From: Marco Marzetti <[email-masked]>
Date: Wed, 15 Jun 2016 16:32:29 +0200

> point is not to explore all possible hacks, but to explain why this

I raised the same question a few weeks ago on this list.
The answer was: because you can never know and IDR should always address 
all the possible cases.

My opinion is that this brings more problems than benefits (because 
stupid people do stupid things), but i think that the new lines make it 
clear enough that adding the ASn of the RS in the AS_PATH is a very bad 
idea.

-- 
Marco

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Jun 2016 10:40:12 -0400

On Wed, Jun 15, 2016 at 10:32 AM, Marco Marzetti <[email-masked]> wrote:

> but i think that the new lines make it clear enough that adding the ASn of
> the RS in the AS_PATH is a very bad idea.

​so... for clarity... 'very bad idea', isn't really right. It's
inconvenient, and a change in behaviour of a running RS would  be
chaotic/painful/etc, but .. if you knew going into the RS
connection/process that this was the case you could adjust for it.

Admittedly it's painful, but it's not 'very bad idea', like 'our rs only
does eigrp!' (or similar tomfoolery). We should be careful about overly
hyperbolic phrasing, I think.​

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 17 Jun 2016 12:45:22 +0200

Hi all,

sorry for my late reply. Yes, that was not capturing my point. Please provide some reasoning with the SHOULD is not a MUST. What are the cases where you should not follow the SHOULD.

Mirja

> Am 14.06.2016 um 19:08 schrieb Randy Bush <[email-masked]>:
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Jun 2016 09:11:12 -0400

> be a MUST.  why allow the loophole?  i admit my example was baroque.

I am somewhat late in chiming in on this thread, but I'm also supportive of
making this a MUST.

If you're intending to inject your AS number into the path, then you're
acting as a standard BGP speaker, not a Route Server.

If the intent of the text in the current internet-draft is to leave wiggle
room for a device operating as a RS to also act as a standard BGP speaker
without RS functionality, I think that's unnecessary.

-- Jeff

---

From: [email-masked] (Niels Bakker)
Date: Mon, 20 Jun 2016 18:30:49 +0200

* [email-masked] (Jeffrey Haas) [Mon 20 Jun 2016, 15:05 CEST]:
>If you're intending to inject your AS number into the path, then 
>you're acting as a standard BGP speaker, not a Route Server.

Not if you're doing multiple (per-peer) RIBs to avoid the path-hiding 
problem.

	-- Niels.

--

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Jun 2016 20:24:14 +0200

Jeff,

> making this a MUST.

​As discussed before I disagree. Injecting AS(es) is a simplest form of
making some paths less preferable then others. ​And per peer policy asking
RS send my paths to peers X,Y, Z with + 4 ASes, but to peer A, B, C do not
prepend as Niels points out maybe there already today.

> acting as a standard BGP speaker, not a Route Server.

​To me the Route Server is a Route Reflector for EBGP sessions. It really
does not matter if you are messing with AS_PATH there or not. What actually
matters ​is that you do not set next hop to yourself there.

Cheers,
R.

---

From: Marco Marzetti <[email-masked]>
Date: Mon, 20 Jun 2016 23:43:52 +0200

On 2016-06-20 20:24, Robert Raszuk wrote:
> ​As discussed before I disagree. Injecting AS(es) is a simplest form
> of making some paths less preferable then others. ​And per peer
> policy asking RS send my paths to peers X,Y, Z with + 4 ASes, but to
> peer A, B, C do not prepend as Niels points out maybe there already
> today.
> 
>> you're
> ​To me the Route Server is a Route Reflector for EBGP sessions. It
> really does not matter if you are messing with AS_PATH there or not.
> What actually matters ​is that you do not set next hop to yourself
> there.

I would like to underline that this draft depicts the behavior of a 
route server in an IXP environment.
And, for many reasons, an IXP should be as transparent as possible when 
it comes to route propagation.

-- 
Marco

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Jun 2016 23:56:46 +0200

Hi Marco,

Altering AS_PATH indeed does not happen that often. Let's put that one
aside keeping in mind that practical use cases exists where adding an AS is
needed which to me precludes "MUST".

But I can't agree with statement that IXP RS "should be as transparent as
possible to route propagation" as every IX which assists in routes handling
offers extensive RS to client (and to some level even client to RS)
filtering policies.

Ref:
https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers

That proves black on white that "transparency" is gone. Now the question is
if we should RFC something which would be completely unpractical or
unusable ?

Many thx,
R.

On Mon, Jun 20, 2016 at 11:43 PM, Marco Marzetti <[email-masked]> wrote:

> I would like to underline that this draft depicts the behavior of a route
> server in an IXP environment.
> And, for many reasons, an IXP should be as transparent as possible when it
> comes to route propagation.
>
> --
> Marco
>

---

From: Marco Marzetti <[email-masked]>
Date: Thu, 23 Jun 2016 15:18:36 +0200

On 2016-06-20 23:56, Robert Raszuk wrote:
> aside keeping in mind that practical use cases exists where adding an
> AS is needed which to me precludes "MUST".
> 
> But I can't agree with statement that IXP RS "should be as transparent
> as possible to route propagation" as every IX which assists in routes
> handling offers extensive RS to client (and to some level even client
> to RS) filtering policies.
> 
> Ref:
> That proves black on white that "transparency" is gone. Now the
> question is if we should RFC something which would be completely
> unpractical or unusable ?
> 
> Many thx,
> R.

Robert,

My apologies if it took me so long to reply.

Even if i agree on some of your points we obviously have very different 
opinions.
And it is kinda funny that you've linked a documents that says

"""
Maintain your peering policy
The route server has built in filters that allow you to maintain your 
peering policies
"""

How could I maintain my peering policy if for whatever reasons the route 
server is adding its ASn in the PATH?

Anyway, as said, i agree that the are some very particular cases in 
which that is needed.
On top of all of them: the BGP stacks that rely on that behavior for 
whatever reason.

That said i would like to clarify that i'd really prefer that the author 
use MUST instead of SHOULD (because, in my opinion, we should have those 
stacks fixed instead of adjusting a standard to embrace them) but i 
agree that it may not be advisable for the time being.

So i think that we can use SHOULD and add further clarification that 
explains why that should be avoided when possible.

Regards

-- 
Marco

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 24 Jun 2016 19:47:36 +0100

Robert Raszuk wrote:
> What actually matters ​is that you do not set next hop to yourself there. 

yes, this is what makes a standard bgp speaker a route server.  The core
functionality is distributing prefixes on a shared broadcast domain, but
without routing the actual traffic.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 24 Jun 2016 20:41:29 +0100

> without RS functionality, I think that's unnecessary.

the intent is to acknowledge that there are some bgp stacks which cannot
handle leftmost as != peer as when acting as an rs client. Mostly these
stacks are legacy, but there are still some bgp implementations which
don't support this feature on the client side, even though the client
side part is mandated further down the paragraph.

If the SHOULD is changed to MUST, then the IXP operator will not be able
to provide RS service to clients like this.  This is not a helpful thing
to do from a operational point of view.

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 Jun 2016 22:05:21 +0200

> to do from a operational point of view.

though i have little sympathy for folk who want to connect broken home
appliances to exchanges, at least thie answers the AD's question.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 24 Jun 2016 22:16:36 +0100

Mirja Kuehlewind (IETF) wrote:
> sorry for my late reply. Yes, that was not capturing my point. Please
> provide some reasoning with the SHOULD is not a MUST. What are the
> cases where you should not follow the SHOULD.

Ok.  I've changed the text to read:

> 2.2.2.1. Route Server AS_PATH management
> 
> As a route server does not participate in the process of forwarding
> data between client routers, and because modification of the AS_PATH
> attribute could affect route server client BGP Decision Process, the
> route server SHOULD NOT prepend its own AS number to the AS_PATH
> segment nor modify the AS_PATH segment in any other way. This differs
> from the behaviour specified in section 5.1.2 of [RFC4271], which
> requires that the BGP speaker prepends its own AS number as the last
> element of the AS_PATH segment. This is a recommendation rather than
> a requirement solely to facilitate legacy RS client implementations
> which do not yet support the requirements specified in Section
> 2.2.2.2.
> 
> 2.2.2.2. Route Server client AS_PATH management
> 
> In contrast to what is recommended in section 6.3 of [RFC4271], [...]

This splits up 2.2.2 into two sub paragraphs and adds a sentence to the
end of the first paragraph which refers to the second.

Does this work for you, or would you prefer if -12 were posted before
commenting?

Nick