Subject: [Idr] Low-order attribute flags -- when to zero

From: John Scudder <[email-masked]>
Date: Thu, 13 Dec 2012 17:04:26 -0500

Folks,

It recently came to my attention that the following from RFC 4271 has been interpreted in at least two different ways:

4.3.  UPDATE Message Format
...
      Path Attributes:
...
         The lower-order four bits of the Attribute Flags octet are
         unused.  They MUST be zero when sent and MUST be ignored when
         received.

Specifically, the disagreement is regarding "when sent". One school of thought holds that this means "when originated". Another holds that it means "when originated or propagated."

I'm inclined toward the "when originated" interpretation. This is basically because for transitive attributes, reserved flags aren't good for much if people go resetting them all the time, just for fun. Thus, it makes sense to originate the flags as zero, but to transit them as received. 

I would like to open an erratum against RFC 4271 to clarify this. Some proposed text is below. I thought I'd open the floor for discussion before I file anything. We'd end up discussing it anyway, so this just saves one step in processing the erratum.

Also: even if we don't use my proposed text, it's demonstrably the case that the text as written is insufficiently clear. Thus we need SOME erratum to clarify it, to whatever the WG consensus is.

Thanks,

--John

Suggested text:

Type: Technical
Section: RFC 4271 Section 4.3
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.  When received, any
         value MUST be accepted.  When a BGP speaker propagates an 
         attribute, it MUST propagate these flags as received.

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 13 Dec 2012 22:40:58 +0000

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
>       Specifically, the disagreement is regarding "when sent". One school of thought
>       holds that this means "when originated". Another holds that it means "when origin
>       ated or propagated."
Actually you have some vendors that strictly follow that text.
While they IGNORE those bits they always 0 them too (ok that is not quite ignoring but I see that vendor's point)

Another vendor ignores those bits but propagated them (non-zero).

Another vendor depending on code base drops the peering session if those bits are set but sets those bits under special conditions on a different code base.

>
>       I'm inclined toward the "when originated" interpretation. This is basically because
>       for transitive attributes, reserved flags aren't good for much if people go
>       resetting them all the time, just for fun. Thus, it makes sense to originate the
>        flags as zero, but to transit them as received.
>
>       I would like to open an erratum against RFC 4271 to clarify this. Some proposed
>       text is below. I thought I'd open the floor for discussion before I file anything.
>       We'd end up discussing it anyway, so this just saves one step in processing
>       the erratum.
>
>       Also: even if we don't use my proposed text, it's demonstrably the case that the
>        text as written is insufficiently clear. Thus we need SOME erratum to clarify it,
>        to whatever the WG consensus is.
>
>       Thanks,
>
>       --John
>
>       Suggested text:
>
>       Type: Technical

This is acceptable from a RFC pov in my view but there are vendors that will drop the peering session if the lower-order (nible) four bits are set. So today this breaks stuff. Vendors have been requested to 0 those bits and ignore them from a peering pov (ignoring an attribute with those bits set).

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

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 13 Dec 2012 22:58:21 +0000

Our code stores known attributes in an abstracted fashion and
rebuilds them when writing the UPDATE message.
It does this explicitly to prevent our peers barfing on
bad reserved bits.
Unknown optional transitive attributes are retransmitted verbatim.
BTW, we ignore those bits on receipt.

I think the horse has left the barn.
There are routers out there that (mistakenly) barf when receiving
those bits as non-zero.
If we change the code to propagate the bad bits, we'll suddenly
see more sessions resetting.

Maybe, you can change your last sentence to:
          When a BGP speaker propagates an 
          unknown optional transitive attribute,
          it MUST propagate these flags as received.

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of John Scudder
> Sent: Thursday, December 13, 2012 2:04 PM
> To: idr@ietf. org
> Subject: [Idr] Low-order attribute flags -- when to zero
> 
> Folks,
> 
> It recently came to my attention that the following from RFC 
> 4271 has been interpreted in at least two different ways:
> 
> Specifically, the disagreement is regarding "when sent". One 
> school of thought holds that this means "when originated". 
> Another holds that it means "when originated or propagated."
> 
> I'm inclined toward the "when originated" interpretation. 
> This is basically because for transitive attributes, reserved 
> flags aren't good for much if people go resetting them all 
> the time, just for fun. Thus, it makes sense to originate the 
> I would like to open an erratum against RFC 4271 to clarify 
> this. Some proposed text is below. I thought I'd open the 
> floor for discussion before I file anything. We'd end up 
> discussing it anyway, so this just saves one step in 
> processing the erratum.
> 
> Also: even if we don't use my proposed text, it's 
> demonstrably the case that the text as written is 
> insufficiently clear. Thus we need SOME erratum to clarify 
> it, to whatever the WG consensus is.
> 
> Thanks,
> 
> --John
> 
> Suggested text:
> 
> Type: Technical
> [email-masked]

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 13 Dec 2012 18:39:31 -0500

> Specifically, the disagreement is regarding "when sent". One school of thought holds that this means "when originated". Another holds that it means "when originated or propagated."

I'm glad there is some interest in this, because it caused me and
others some operational headaches recently.

>          attribute, it MUST propagate these flags as received.

I wish the flags would be propagated as received.  I feel this is
correct.  However, I can't wrap my head around the leap of logic that
makes this a MUST.  In one sentence, it is forbidden to originate an
attribute with these bits != 0x0.  In the same paragraph, you must
take care to preserve their value in case they are != 0x0 anyway.

IMO if that is to be changed, then the text opens up the door to
originating the attribute and then modifying it later by setting these
bits, as not being illegal; but it is illegal to set them at
origination.  How strange is that?

I imagine some vendors have got complaints that they didn't zero these
bits on propagation.  I'm not complaining to my vendor not because of
ambiguity, but because my downstream customer's BGP implementation was
wrong by not ignoring the bits, and that's as far as I was willing to
argue it.

If any change, I think MUST be zero when sent =/= SHOULD be zero when
sent, and just remove all ambiguity about whether or not these bits
may be used for some vendor-private extension or whatever.  The change
you are proposing essentially has the same affect.

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

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 13 Dec 2012 19:49:37 -0500

Jeff,

> take care to preserve their value in case they are != 0x0 anyway.

Exactly. This was my point in writing "this is basically because for transitive attributes, reserved flags aren't good for much if people go resetting them all the time, just for fun", but I see I should have spent a few more words on the rationale.

Basically, reserved flags are only useful if there is some hope of someday using them for something. If implementations go resetting the flags, then some future revision to the spec that introduced a new flag would have no hope of that flag propagating end to end, since it would be very likely that some well-meaning intermediate router would stomp on it. The effort to roll out implementations that transited the new flag would almost certainly be prohibitive.

I have no current use for the reserved flags in mind, but I'm hesitant to throw out a potentially valuable resource for future extension.

> origination.  How strange is that?

Well, "modifying it later" wasn't my intention, and I think also not permitted by what I wrote. It's true that if some router DID modify it later, the text I offered would propagate the modified flag. Then again, see above: maybe that modification would be for a good well-specified reason. 

It comes down to a case of "Be conservative in what you send, liberal in what you accept."

--John

---

From: Shyam Sethuram <[email-masked]>
Date: Thu, 13 Dec 2012 19:07:40 -0800

Unfortunately given the current implementations out there, we'll never
be able to introduce a new Flag :(

The Neighbor-Complete flag in draft-ietf-idr-optional-transitive-02 is
one such example that was nixed because of this.

But it is still worth adding the Errata as you said.

shyam

On Thu, Dec 13, 2012 at 4:49 PM, John G. Scudder <[email-masked]> wrote:

> Exactly. This was my point in writing "this is basically because for
> transitive attributes, reserved flags aren't good for much if people go
> resetting them all the time, just for fun", but I see I should have spent a
> few more words on the rationale.
>
> Basically, reserved flags are only useful if there is some hope of someday
> using them for something. If implementations go resetting the flags, then
> some future revision to the spec that introduced a new flag would have no
> hope of that flag propagating end to end, since it would be very likely
> that some well-meaning intermediate router would stomp on it. The effort to
> roll out implementations that transited the new flag would almost certainly
> be prohibitive.
>
> I have no current use for the reserved flags in mind, but I'm hesitant to
> throw out a potentially valuable resource for future extension.
>
> Well, "modifying it later" wasn't my intention, and I think also not
> permitted by what I wrote. It's true that if some router DID modify it
> later, the text I offered would propagate the modified flag. Then again,
> see above: maybe that modification would be for a good well-specified
> reason.
>

---

From: Tony Li <[email-masked]>
Date: Thu, 13 Dec 2012 19:45:53 -0800

>         attribute, it MUST propagate these flags as received.

John,

My recollection was that the intent is captured by the corrected text.  

Will the RFC Editor accept this as a Erratum?  In the past, when we've suggested similar technical changes, they've been rebuffed.

Tony

---

From: John Scudder <[email-masked]>
Date: Fri, 14 Dec 2012 03:59:04 +0000

> Will the RFC Editor accept this as a Erratum?  In the past, when we've suggested similar technical changes, they've been rebuffed.

Well, we don't know until we try. The reason I think there's a strong case for this to be an erratum is that it's demonstrably unclear in the current text, in that different implementors have done different things, not out of any willful desire to diverge from the spec, but because that's what they thought it said. Seems to me like exactly what a technical erratum is for. 

--John

---

From: <[email-masked]>
Date: Fri, 14 Dec 2012 13:27:42 +0000

John, all

Please find below some comments inline.

>From: John Scudder
>
>Folks,
>
>It recently came to my attention that the following from RFC 4271 has been
>interpreted in at least two different ways:

Thanks for raising and clarifying the point.

>holds that this means "when originated". Another holds that it means "when
>originated or propagated."
>
>I'm inclined toward the "when originated" interpretation. This is basically
>because for transitive attributes, reserved flags aren't good for much if
>people go resetting them all the time, just for fun. Thus, it makes sense to
>originate the flags as zero, but to transit them as received.

+1

In my view, this is not limited to transitive attributes. IMHO, we could possibly specify new usage for those bits even for non-transitive or even well-known attributes.

>text is below. I thought I'd open the floor for discussion before I file
>anything. We'd end up discussing it anyway, so this just saves one step in
>processing the erratum.
>
>Also: even if we don't use my proposed text, it's demonstrably the case that
>the text as written is insufficiently clear. Thus we need SOME erratum to
>clarify it, to whatever the WG consensus is.

+1

>         unused.  They MUST be zero when originated.  

+1

Possibly :s/unused/currently unused and reserved for future extension
As clarifying the goal of those bits may help the readers to take the right assumption in case some of further questions.

> When received, any value MUST be accepted.

+1

>  When a BGP speaker propagates an attribute, it MUST propagate these flags as received.

+1

Thanks,
Bruno

_________________________________________________________________________________________________________________________

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: "Chris Hall" <[email-masked]>
Date: Fri, 14 Dec 2012 15:37:11 -0000

Jakob Heitz wrote (on Thu 13-Dec-2012 at 22:58 +0000):
...
> I think the horse has left the barn.

There was a horse ?!

I read the requirement as tacit acceptance that it is never going to
be possible to fiddle with the base level Flags handling.

If there is doubt whether "sent" might mean just when "originated",
then it could be made clear that the sender MUST *always* flatten to
zeros (just in case the receiver is a blithering idiot and fails to
flatten to zeros).

Obviously these bits could be given meaning, between consenting peers
who have negotiated their way into a state of (mutual) sin.  Although,
that could disrupt code which is processing UPDATE messages
"out-of-band" :-(

...
>           it MUST propagate these flags as received.

Is this a big win ?  If an optional transitive attribute needs a few
bits, why not just include them in the body of the attribute ?

Further, it's simpler and more reliable if the receiver can treat all
attributes the same, and mask off the "unused" bits.

Mind you, in the Flags octet only Transitive and Extended Length have
any useful meaning.  And Transitive is only meaningful on Unknown
attributes.  Otherwise, the bits are pretty much noise, and once
draft-ietf-idr-error-handling has had its wicked way with them, the
noise will be suppressed.

[Does anyone know what the "Partial" bit is for, BTW ?]

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 14 Dec 2012 16:01:32 +0000

> There was a horse ?!

Here is the horse:

On Dec 9, 2012, at 6:26 PM, "Jeff Wheeler" <[email-masked]> wrote:
> Here is an example from two weeks ago of some routes injected to the
> DFZ with malformed attribute flags.  The result was that everyone
> running OpenBGPd more than a few months old, and some networks with
> Alcatel routers, and who knows what else, had their BGP sessions
> resetting endlessly.
> http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html

If the working group is fine with resetting sessions on those routers, I'll happily change my code.

--
Jakob Heitz.

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 14 Dec 2012 13:54:38 -0500

> Well, "modifying it later" wasn't my intention, and I think also not permitted by what I wrote. It's true that if some router DID modify it later, the text I offered would propagate the modified fl…

If you carefully parse the text you've written, it does indeed allow
intermediate routers to modify the reserved bits.  That's why I said I
think it is a strange leap of logic.

Basically it is unfortunate that ambiguity has caused different
implementations to behave in different ways here, but I think it is
hard to fix in a sensible way without re-defining the rules so that
the implementations which do NOT reset the bits to 0 are suddenly
out-of-spec.

It makes perfect sense that those bits are RESERVED.  It was done for
octet-alignment and without any anticipation that they would be
needed.  If people are using them for something, I think that's fine,
and perhaps they would care to modify BGP so the reserved bits SHOULD
be zero instead of MUST be zero.  i understand why this cannot be done
as an errata but ultimately it is the correct "fix," if the goal is to
modify the specification to fit some corner-cases in the real world.

> [Does anyone know what the "Partial" bit is for, BTW ?]

Yes, the Partial Bit is documented in RFC4271 Pg24.  Basically, it's
there for two reasons.

First, if you propagate an unrecognized transitive optional Attribute,
you are supposed to set the Partial bit.  This indicates to other BGP
speakers that, if you were supposed to modify this attribute (if you
knew what it was) you did not do this (because you don't know how.)

An example of this is that crazy private AS / administrative domain
identifier attribute.  Say you added that to the BGP specification as
a new attribute.  Routers that did not know what to do with it would
happily forward the attribute and set Partial on it.  Implementing
that feature would not need the information carried in the Partial
bit, but it's there just in case.

Also if you add an optional transitive attribute, you are supposed to
set the Partial bit, if you are not the originator of the path -- in
other words, you are a transit router.

> If the working group is fine with resetting sessions on those routers, I'll happily change my code.

I guess that is a joke I didn't get?  I did not think it was funny
when I had to troubleshoot it in the middle of the night!  :-(

---

From: Chris Hall <[email-masked]>
Date: Fri, 14 Dec 2012 23:01:41 +0000

> other words, you are a transit router.

It's a bundle of laughs.  No question.

So, I'm staring at an attribute with a Partial bit on it, which means:

  1) my immediate neighbour did not understand the attribute,

  2) somebody upstream of my neighbour did not understand it,

  3) somebody other than the originator added it,

  4) or any combination of the above,

I think that's all the possible meanings... plenty to choose from :-)... it's possible that something about the attribute will resolve this ambiguity... or not; who can tell ?

Chris

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 14 Dec 2012 19:04:45 -0500

> I think that's all the possible meanings... plenty to choose from :-)... it's possible that something about the attribute will resolve this ambiguity... or not; who can tell ?

The important thing is what Partial=0 means: the attribute was placed
there by the originator and understood by all "upstream" BGP speakers.

I don't know why it isn't documented that way.  Maybe historical?

---

From: t.petch <[email-masked]>
Date: Mon, 17 Dec 2012 21:23:06 +0000

I had a look at RFC1771 and it says

"The lower-order four bits of the Attribute Flags octet are .
         unused. They must be zero (and must be ignored when received)."
which I find interestingly different (and clearer).

Looking back at revisions thereof, the text changed between January and
September 2001 but I have not tracked any discussions as to why.

Tom Petch

----- Original Message -----
From: "John Scudder" <[email-masked]>
To: "idr@ietf. org" <[email-masked]>
Sent: Thursday, December 13, 2012 10:04 PM

> Folks,
>
> It recently came to my attention that the following from RFC 4271 has
been interpreted in at least two different ways:
> Specifically, the disagreement is regarding "when sent". One school of
thought holds that this means "when originated". Another holds that it
means "when originated or propagated."
>
> I'm inclined toward the "when originated" interpretation. This is
basically because for transitive attributes, reserved flags aren't good
for much if people go resetting them all the time, just for fun. Thus,
it makes sense to originate the flags as zero, but to transit them as
received.
>
> I would like to open an erratum against RFC 4271 to clarify this. Some
proposed text is below. I thought I'd open the floor for discussion
before I file anything. We'd end up discussing it anyway, so this just
saves one step in processing the erratum.
>
> Also: even if we don't use my proposed text, it's demonstrably the
case that the text as written is insufficiently clear. Thus we need SOME
erratum to clarify it, to whatever the WG consensus is.