Subject: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01

From: "John G. Scudder" <[email-masked]>
Date: Wed, 13 Mar 2013 13:43:13 -0400

In parallel to the call for adoption I'd like to encourage discussion on the following, in hopes of moving this through the rest of the process as fast as possible --

1. There appears to me to be a consensus that we should set the low attribute flag bits to be zero at all times. (Basically, declare them to be "toxic" and sanitize them aggressively.) The show of hands at today's in-person meeting (and on Jabber) seemed to confirm this.

Q: Does the WG agree? In particular, if you don't agree, please speak up.

2. Must-be-zero is what the current (-01) version of the draft says, or intends to say. There's also the question of whether -01 says it in the most useful, unambiguous way. There is probably room for improvement.

Q: Please send text!

Thanks,

--John

---

From: t.petch <[email-masked]>
Date: Thu, 14 Mar 2013 13:59:00 +0000

---- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "idr wg" <[email-masked]>
Sent: Wednesday, March 13, 2013 5:43 PM

In parallel to the call for adoption I'd like to encourage discussion on
the following, in hopes of moving this through the rest of the process
as fast as possible --

1. There appears to me to be a consensus that we should set the low
attribute flag bits to be zero at all times. (Basically, declare them to
be "toxic" and sanitize them aggressively.) The show of hands at today's
in-person meeting (and on Jabber) seemed to confirm this.

<tp>
You seem to be saying that these bits are out of commission for all
time, that they never, ever can be used.

I think that this is the wrong approach.

Tom Petch

Q: Does the WG agree? In particular, if you don't agree, please speak
up.

2. Must-be-zero is what the current (-01) version of the draft says, or
intends to say. There's also the question of whether -01 says it in the
most useful, unambiguous way. There is probably room for improvement.

Q: Please send text!

Thanks,

--John

------------------------------------------------------------------------
--------

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

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 14 Mar 2013 14:25:45 +0000

Nope. They are our rules. We can change them again.

If someone comes up with a use for them that works and doesn't risk session resets, I, for one, would be happy to change the rule.

________________________________
From: [email-masked] [[email-masked]] on behalf of t.petch [[email-masked]]
Sent: Thursday, 14 March 2013 6:59 AM
To: John G. Scudder; idr wg
Subject: Re: [Idr] Discussion questions fordraft-hares-idr-update-attrib-low-bits-fix-01

---- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "idr wg" <[email-masked]>
Sent: Wednesday, March 13, 2013 5:43 PM

<tp>

Tom Petch

Q: Please send text!

Thanks,

--John

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 14 Mar 2013 21:29:04 -0400

> I think that this is the wrong approach.

It would be very hard to use them in any inter-domain capacity; and
require an AS-wide effort to use them even internally.

The John/Susan draft does not change anything.  It is not a revision
to the spec.  It's just changing a few words because some people were
doing the wrong thing, and indicated that they thought the language
was ambiguous.

So if you wanted to make the reserved bits useful, it would not be
harder after adoption of this document.

For that reason, I don't think it's useful to discuss it in the
context of this particular paragraph.  If you want to use the reserved
bits for something, that's different!

--
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 18:16:03 +0000

Hi all,

0.       I support the adoption of this draft.

1.       I support the proposed solution (always 0) as the most pragmatic in the current context.

2.       "They MUST be zero when originated or propagated."
I'm fine with the text. However in BGP I could see 3 cases:
Originated: a new attribute is attached to a path not already having this attribute type.
Modified: an attribute of that type was present but its value has been changed by the BGP router.
Propagated unchanged: the BGP route is propagated with the attribute value unchanged.

Do we want to introduce such definitions so that they may be referred to latter?
Do we want to include these 3 cases in the text? (Although I agree that in this specific text, whichever is the interpretation of the missing one this will not change the result (as although one could classify "modified" into "originated" or "propagated", both have the same action).

Also FWIW, https://tools.ietf.org/html/rfc4271#section-5 seems to use the terms "attached", "attached by the originator" and "passed" (rather than "originated", "propagated", "modified"). Do we want to keep those terms or use new ones?

Regards,
Bruno

From: [email-masked] [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Wednesday, March 13, 2013 1:43 PM
To: idr wg
Subject: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01

Q: Please send text!

Thanks,

--John

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 18 Mar 2013 08:27:29 -0400

> Do we want to introduce such definitions so that they may be referred to

That seems like it would be expanding the scope of something which is
currently quite specific and targeted at confusion that can be proved
to have produced bugs.

Your idea is wise but maybe should be held for the next BGP
specification update.  No doubt it will need one, once a few more
vendors glue BGP into ToR switches and start using it to signal PoE
configuration or some other crazy thing!