Subject: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

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

Folks,

The authors (i.e., Sue and me) have requested IDR adopt draft-hares-idr-update-attrib-low-bits-fix-01 as a working group document.

Please send any comments to the list by March 27.

Thanks,

--John & Sue

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 13 Mar 2013 17:45:43 +0000

support

Cheers,
Jeff

From: John Scudder <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 13, 2013 9:43 AM
To: "idr@ietf. org" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Folks,

Thanks,

--John & Sue

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 13 Mar 2013 17:46:58 +0000

support

________________________________
From: [email-masked] [[email-masked]] on behalf of John Scudder [[email-masked]]
Sent: Wednesday, 13 March 2013 10:43 AM
To: idr@ietf. org
Subject: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Folks,

Thanks,

--John & Sue

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 13 Mar 2013 17:46:03 +0000

support

From: John Scudder <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 13 March 2013 18:43
To: "idr@ietf. org" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Folks,

Thanks,

--John & Sue

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 13 Mar 2013 18:25:30 +0000

Support. Comments :

This problem statement makes sense but I am not sure you clarified "when sent".
That is you still used sent in the corrected text. Wouldn't it be better to say "when originated or propagated" if that is what we are trying to clarify?

   The issue has been that one school of thought considers that "when
   sent" means when originated.  Another holds that "when sent" means
   when originated or propagated.  This draft takes the second approach
   of "when sent" being when originated or propagated.

   The real issue is that reserved flags are only useful if there is
   some hope of someday using them for something.  If implementations
   reset these flags on propagation, then a future revision to the BGP
   specification which introduces a new flag will not be able to
   propagate the new attribute flag end to end, since it would be very
   likely that some well-meaning intermediate router would zero on it.
   The effort to roll out implementations that transited the new flag
   would almost certainly be prohibitive.

2.  Change to RFC 4271 Section 4.3

                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |  Attr. Flags  |Attr. Type Code|
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Original Text:

            The lower-order four bits of the Attribute Flags octet are
            unused.  They MUST be zero when sent and MUST be ignored when
            received

            Corrected Text:

            The lower-order four bits of the Attribute Flags octet are
            unused.  They MUST be zero when originated or sent.
            When received, any MUST be accepted and ignored.

So maybe "They MUST be zero when originated or propagated"?

However that doesn't allow us to ever use those 4 bits. I am ok with that if that is the intention. I don't see how to allow propagation until various bgp implementations are fixed which may never happen?

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: John Scudder <[email-masked]>
Date: Wednesday 13 March 2013 18:43
To: "idr@ietf. org" <[email-masked]>
Subject: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Folks,

Thanks,

--John & Sue

---

From: Jeff Wheeler <[email-masked]>
Date: Wed, 13 Mar 2013 14:58:02 -0400

> However that doesn't allow us to ever use those 4 bits. I am ok with that if that is the intention. I don't see how to allow propagation until various bgp implementations are fixed which may never…

There is a lot of discussion on the mailing list about this topic in
the past two months.  You may wish to skim the list archive.

It would be really tough to use these bits.  The problem isn't just
the small number of DFZ routers that would break upon receiving an
attribute with the reserved bits set.  It is also that so many routers
zero-out the bits, you could not rely on a reserved bit being 0 as
information.  http://inconcepts.biz/~jsw/bgp_attrib_flags_problem.pdf
slide #20 explains one way you could use them, but it basically has to
solve the same problem IP ECN did with loss of information in-transit.

Because there is no practical application for the reserved bits at
this time, I think it unnecessary to further discuss making them
useful, but I did write some detailed posts to the list on this topic.

There really is no change being made to the BGP spec here.  It has
always said to zero these bits.  Some people managed to misinterpret
that, so here we are switching a few words around to still end up with
the same thing.

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

---

From: David Farmer <[email-masked]>
Date: Wed, 13 Mar 2013 14:06:23 -0500

Support adoption;

I would prefer the Corrected Text be the following:

             The lower-order four bits of the Attribute Flags octet are
             unused.  They MUST be zero when originated or propagated.
             When received, any MUST be accepted and ignored.

Completely eliminate the word "sent"

While I'm not wild about propagate as zero, it is acceptable.  However, 
the point of the third paragraph of the introduction and the addition of 
the last sentence in the corrected text must be driven home.  It is not 
acceptable for an implementation to reset a connection or anything else 
if they are not zero.

There may come a day when we use these bits and they will get loose in 
the wild and therefore "When received, any MUST be accepted and 
ignored," must be implemented and should be added to conformance and 
regression testing suites by everyone.

Thanks.

On 3/13/13 12:43 , John Scudder wrote:
> Folks,
>
> The authors (i.e., Sue and me) have requested IDR adopt
> draft-hares-idr-update-attrib-low-bits-fix-01 as a working group document.
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 13 Mar 2013 19:22:07 +0000

I did read all of the threads on this some of them I had to read a few times. Yes, I understand those bits are probably unusable at least for the foreseeable future.
The main issue was the "sent" rather than propagated in the new language.

So I recommend the use of propagated to clear up the possible confusion.

There is also a minor (nit) grammar mistake here:

   Compliance with this draft, as well as [RFC4271], means that routers
   should not reset BGP sessions if if non-zero lower bits are received.

Should be this:
   Compliance with this draft, as well as [RFC4271], means that routers
   should not reset BGP sessions if non-zero lower bits are received.

From: Jeff Wheeler [[email-masked]]
Sent: Wednesday, March 13, 2013 12:58 PM
To: Smith, Donald
Cc: [email-masked]
Subject: Re: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

---

From: t.petch <[email-masked]>
Date: Wed, 13 Mar 2013 20:52:29 +0000

adopt

Tom Petch

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

Folks,

The authors (i.e., Sue and me) have requested IDR adopt
draft-hares-idr-update-attrib-low-bits-fix-01 as a working group
document.

Thanks,

--John & Sue

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

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 13 Mar 2013 18:07:17 -0400

Support 

-Jon

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 13 Mar 2013 22:41:43 +0000

John, Sue

In today's meeting there was an ask for two implementation of AIGP in order to advance the draft.. both Juniper and Cisco have implemented it..

Jim Uttaro

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Mar 2013 23:44:37 +0100

Support.

r.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 13 Mar 2013 22:45:20 +0000

+1

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, March 13, 2013 6:45 PM
To: John Scudder
Cc: idr@ietf. org
Subject: Re: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Support.

r.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 13 Mar 2013 22:53:26 +0000

Alu as well.

Cheers,
Wim
_________________
sent from blackberry

From: UTTARO, JAMES [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 11:41 PM
To: 'John Scudder' <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] AIGP Progression

John, Sue

In today’s meeting there was an ask for two implementation of AIGP in order to advance the draft.. both Juniper and Cisco have implemented it..

Jim Uttaro

---

From: "Fragassi, Roberto (Roberto)" <[email-masked]>
Date: Thu, 14 Mar 2013 00:17:15 +0000

Support

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Wednesday, March 13, 2013 1:43 PM
To: idr@ietf. org
Subject: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Folks,

Thanks,

--John & Sue

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 09:06:39 +0100

Support.

Cheers,

Christian.

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de John Scudder
Envoyé : mercredi 13 mars 2013 18:43
À : idr@ietf. org
Objet : [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Folks,

Thanks,

--John & Sue

_________________________________________________________________________________________________________________________

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: "Susan Hares" <[email-masked]>
Date: Thu, 14 Mar 2013 06:39:22 -0400

Donald :

Randy also suggested the following change:  

"They MUST be zero when originated or propagated"?

This is reflected in the IDR slides.   It will never allow us to use these
bits.  Bad things can happen without the solution being implemented in all
routers.  

Thanks for all the great questions.  Did I answer all the questions you
raised?

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Smith,
Donald
Sent: Wednesday, March 13, 2013 2:26 PM
To: Henderickx, Wim (Wim); John Scudder; idr@ietf. org
Subject: Re: [Idr] WG adoption requested for
draft-hares-idr-update-attrib-low-bits-fix-01

Support. Comments :

This problem statement makes sense but I am not sure you clarified "when
sent".
That is you still used sent in the corrected text. Wouldn't it be better to
say "when originated or propagated" if that is what we are trying to
clarify?

            Original Text:

            Corrected Text:

However that doesn't allow us to ever use those 4 bits. I am ok with that if
that is the intention. I don't see how to allow propagation until various
bgp implementations are fixed which may never happen?

From: John Scudder <[email-masked]>
Date: Wednesday 13 March 2013 18:43
To: "idr@ietf. org" <[email-masked]>
Subject: [Idr] WG adoption requested for
draft-hares-idr-update-attrib-low-bits-fix-01

Folks,

Thanks,

--John & Sue

---

From: Russ White <[email-masked]>
Date: Thu, 14 Mar 2013 09:34:33 -0400

Support.

:-)

Russ

<><
[email-masked]
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Mar 2013 10:00:48 -0400

> "They MUST be zero when originated or propagated"?

fwiw, my point was clarifying by using the terms 'originated' and
'propagated'.  i was not stating an opinion on the mbz.  of course i
have one :)

randy

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 14 Mar 2013 14:45:54 +0000

You answered the only real concern that I believe can be addressed.

The other "hidden" item was do we burn those bits forever?

And while we could debate it here all day the fact is someday someone may come up with a way to use those bits and request a change to this draft again so we can't really decide forever we can only decide what todays and the near future behavoir will be.

I support but recommend the originated vs sent language recommendations.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: Susan Hares [[email-masked]]
Sent: Thursday, March 14, 2013 4:39 AM
To: Smith, Donald; 'Henderickx, Wim (Wim)'; 'John Scudder'; 'idr@ietf. org'
Subject: RE: [Idr] WG adoption requested for draft-hares-idr-update-attrib-low-bits-fix-01

Donald :

Sue

-----Original Message-----

Support. Comments :

            Original Text:

            Corrected Text:

Folks,

Thanks,

--John & Sue

---

From: Enke Chen <[email-masked]>
Date: Thu, 14 Mar 2013 10:05:50 -0700

Hi, folks:

I am not sure if we need to clarify the meaning of "sent" because one 
implementation mistakenly confined its meaning to a subset. There have 
been numerous uses of "send as 0 by the sender, and ignored by the 
receiver" for a reserved field in various protocol specs.  If we were to 
march down this path, the amount of work would be endless. It seems to 
me that it should be treated as a bug fix in the implementation.

According to www.dictionary.com, "send" is about "delivery" of a message 
- irrespective of how the message is formed. Its use in RFC4271 seems 
all right.

    send

^1 [send] Show IPA verb, sent, send·ing.
verb (used with object)
1.
to cause, permit, or enable to go: to send a messenger; They sent their 
son to college.
2.
to cause to be conveyed or transmitted to a destination: to send a letter.
3.
to order, direct, compel, or force 
<http://dictionary.reference.com/browse/force>to go: The president sent 
troops to Asia.
4.
to direct, propel, or deliver to a particular point, position, 
condition, or direction: to send a punch to the jaw; The punch sent the 
fighter reeling.
5.
to emit, discharge, or utter (usually followed by off, out, or through 
  ): The lion sent a roar through the jungle.
Relevant Questions
What To Send Soldiers In... 
<http://ask.reference.com/web?q=What%20To%20Send%20Soldiers%20In%20Iraq?&o=100100>
How To Send A Money Orde... 
<http://ask.reference.com/web?q=How%20To%20Send%20A%20Money%20Order?&o=100100>
When To Send Wedding Inv... 
<http://ask.reference.com/web?q=When%20To%20Send%20Wedding%20Invitations?&o=100100>
How To Send An Attachmen... 
<http://ask.reference.com/web?q=How%20To%20Send%20An%20Attachment?&o=100100>

verb (used without object)
9.
to dispatch a messenger, agent, message, etc.
10.
Electricity . to transmit a signal: The ship's radio sends on a special 
band of frequencies.

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Mar 2013 17:30:27 -0400

> march down this path, the amount of work would be endless.

you are the only one suggesting revising old documents

randy

---

From: Enke Chen <[email-masked]>
Date: Thu, 14 Mar 2013 14:39:48 -0700

I am not suggesting revising old documents.  Just the contrary, I do not 
see a need to redefine/clarify the word "send/sent". The definition in 
the dictionary is clear and fits well in the text for the reserved bits 
of the attribute flag.

The effort just seems unnecessary and wasteful for IDR and the IETF.  
(As I am late to the party, I may have missed some context.)

-- Enke

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 15 Mar 2013 07:21:39 -0400

Enke:

This issue was reported caused a real outage.  

We choose to deal with as a query to the community rather than an errata.
The query had enough concern that we wrote a micro-draft.  Please see the
archives. 

By the way, it would be helpful for you to complete the
draft-ietf-idr-error-handling-03 so people can update their error handling
at one time.  We'll put this micro draft through with that cluster. 

As you recall, we're trying to clear off errata and error handling from our
docket so we can focus on new work.  

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke
Chen
Sent: Thursday, March 14, 2013 5:40 PM
To: Randy Bush
Cc: idr wg
Subject: Re: [Idr] WG adoption requested for
draft-hares-idr-update-attrib-low-bits-fix-01

I am not suggesting revising old documents.  Just the contrary, I do not see
a need to redefine/clarify the word "send/sent". The definition in the
dictionary is clear and fits well in the text for the reserved bits of the
attribute flag.

-- Enke

On 3/14/13 2:30 PM, Randy Bush wrote:
>> implementation mistakenly confined its meaning to a subset. There 
>> have been numerous uses of "send as 0 by the sender, and ignored by 
>> the receiver" for a reserved field in various protocol specs.  If we 
>> were to march down this path, the amount of work would be endless.

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 15 Mar 2013 18:52:57 +0000

I support this draft.

I believe that this is the best we can do to limit the damage
due to malformed update messages. It does not recover from the
error, just limits the damage. However, it is unwise to attempt
recovery from a malformed update.

--
Jakob Heitz.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Susan Hares
> Sent: Friday, March 15, 2013 4:22 AM
> 
<snip>
> at one time.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 15 Mar 2013 20:22:35 +0000

Support, same reasons as Jakob.

Regards,
Jeff