Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Jan 2013 14:31:19 -0500

Idr folks: 

May the new year sparkle with joy for you-all. 

Our discussion on the lower-order four bits came to resolution 

to clarify the RFC 4721 text. John and I decided the best way 

to make sure all parties agree to the solution is to float

a mini-draft that summaries this editorial fix to RFC4721.

Because the mini-draft is so simple, we're going to do a 

2 WG adoption and LC call combined.  If anyone objects, we'll

drop back to just a 2 week WG adoption.  

The draft name is: 

 Update Attribute Flag Low Bits Clarification
 draft-hares-idr-update-attrib-low-bits-fix-00

gotten at :

http://datatracker.ietf.org/doc/draft-hares-idr-update-attrib-low-bits-fix/

Purpose is: 

  This draft provides an update to RFC 4721 to clarify the use of the

   lower-order four bits of the Attribute flag in the Update message.

Authors: John Scudder and Sue Hares

Comment early and often.

Sue Hares and  John Scudder

---

From: John Leslie <[email-masked]>
Date: Mon, 7 Jan 2013 15:22:28 -0500

>  draft-hares-idr-update-attrib-low-bits-fix-00

   I think we will need to back off the "MUST propagate these flags
as received".

   We are going to have, for a number of years, legacy equipment
which resets these bits to zero when propagating: after all, it's
100% compliant with 4271 to do so. Also, I don't think we can be
sure that some modification of these bits in propagation will never
prove useful.

   I suggest changing that MUST to a SHOULD:
" 
" 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 SHOULD propagate these flags as received.

--
John Leslie <[email-masked]>

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Jan 2013 06:02:12 +0900

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

this precludes future use where the semantics include [further]
signaling by non-originating hops.

randy

---

From: "Chris Hall" <[email-masked]>
Date: Mon, 7 Jan 2013 21:04:59 -0000

So:

     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.

When a route learned by iBGP is sent to a Confederation Peer (same
Confederation, different Member AS), the LOCAL_PREF may be the same as
when it was received, or may have been changed in the meantime.  Is
that origination or propagation ?

A Route Reflector SHOULD NOT change the LOCAL_PREF, but if it does,
what then ?  And does it make a difference if the LOCAL_PREF is set
(eg by a Route-Map) but the new value happens to be the same as the
old one ?

For an AS_PATH attribute, the originator of the route must be
originating the attribute.  Where the AS_PATH is passed on unchanged,
that looks like propagating the attribute.  But when it is updated, I
assume that's propagating ?   What about adding/removing Confederation
Segments.

And Route Reflector ORIGINATOR_ID and CLUSTER_LIST ?  (OK,
ORIGINATOR_ID is supposed to be passed unchanged... so propagating may
be obvious, in that case.)

And COMMUNITIES ?  If those pass through unchanged, that looks like
propagating ?  But what level of change counts as originating ?

And don't get me started on Extended Communities, where the
transitiveness goes down to the individual community level.

Given the historic confusion, and the small matter of no previous
definition of "originating" or "propagating" an attribute, it seems to
me that this is not a clarification but is retrofitting a new
requirement.

Currently there is no need to store the state of the flags with the
attribute they rode in with.  This new requirement changes that.  Yuck
:-(

Chris

---

From: John Scudder <[email-masked]>
Date: Mon, 7 Jan 2013 16:10:42 -0500

> signaling by non-originating hops.

[and John Leslie made a similar remark]

It doesn't really. Future use would update both 4271 and this spec, so it would supersede what's written here. I tried writing it out with a SHOULD, but it ended up seeming a bit silly:

"... SHOULD propagate these flags as received, although future extensions MAY define different semantics for one or more of these flags, in which case those semantics should be applied instead."

Thing is, every line of every spec the IETF has ever produced is subject to later revision, at least in principle. So why make a special point of calling it out here?

Thanks,

--John

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 7 Jan 2013 21:50:02 +0000

I would rather they "must be zero when sent" as the original draft ALSO states. I know of vendors that do that, others that see anything not zero as malformed and drops the sessions, still others ignore and pass it on.

If routers forward/re-announce as is many systems today will reset the session and begin flapping:(

Or let me ask this differently. Is there a way to make your changes but give the vendors time to address old incorrect interpretations?

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] on behalf of John Scudder [[email-masked]]
Sent: Monday, January 07, 2013 2:10 PM
To: Randy Bush
Cc: idr wg; Hares Susan
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

On Jan 7, 2013, at 4:02 PM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

--John

---

From: Brian Dickson <[email-masked]>
Date: Mon, 7 Jan 2013 17:11:42 -0500

I have an open question, primarily intended for the folks "experimenting"
across the Internet (and causing much excitement):

If there is even the slightest possibility of using some of these bits in
future, REGARDLESS of for what, maybe the need to use them across unaware
parties could be signalled/negotiated?

For example, a new Capability to be negotiated, call it DONT_MESS_WITH.

If negotiated, the unambiguous behavior of "pass unchanged" applies to the
bits in question.

In any other case, any presumption about the bits getting through should
not be made, and the current "MUST BE ZERO" should apply to all.

This would then mean, if NOT negotiated, allow any, but it is okay to stomp
on them (but not required!!).

If the folks USING the bits really want to do more experiments and/or use
them, a quick I-D on the new Capability would be nice, and I would support
it.

While I would lean towards ALWAYS zeroing out the bits, I can see the
argument the other way, and am fine with the current draft in LC,
regardless of whether it is SHOULD or MUST.

Brian

On Mon, Jan 7, 2013 at 3:22 PM, John Leslie <[email-masked]> wrote:

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

---

From: David Farmer <[email-masked]>
Date: Mon, 07 Jan 2013 17:28:01 -0600

On 1/7/13 15:10 , John Scudder wrote:
> It doesn't really. Future use would update both 4271 and this spec, so
> it would supersede what's written here.
...
> Thing is, every line of every spec the IETF has ever produced is subject
> to later revision, at least in principle. So why make a special point of
> calling it out here?

I agree this is how an update should happen.  However, thinking about my 
response to Randy a little more, I would suggest the following 
additional clarification;

     The lower-order four bits of the Attribute Flags octet are
     currently unused flags.  These unused flags MUST be zero when
     originated.  When received, any value MUST be accepted for these
     unused flags.  When a BGP speaker propagates these unused
     flags, they MUST be propagated as received.

This way if a new specification only defined the use of (bit 5) per se, 
and doesn't actually update the first sentence of this paragraph then it 
is still clear what the intent is.  Furthermore, adding "currently" to 
the first sentence moves the focus of the paragraph from defining 
specifically which bits are unused to the appropriate behavior for 
unused flags, whichever are unused at the moment.

As you say, a proper update should "update both 4271 and this spec." 
However, I could easily see a new specification only defining the new 
bit and forgetting to update the first sentence of this paragraph. 
Especially if the update is self-contained and not a holistic RFC 
4721bis type update.

So, while I agree that we shouldn't specifically call-out that this "is 
subject to later revision"  However, a little strategic use of language 
can ensure that the intent remains clear even if future changes aren't 
as clean as we would hope.

By the way, I support this Draft for both WG adoption & WGLC, as I 
believe the changes I'm suggesting are really just editorial in nature.

Thanks
-- 
================================================
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: Jakob Heitz <[email-masked]>
Date: Tue, 8 Jan 2013 00:04:37 +0000

It's too late. Those bits are dead. There's plenty more bits in the sea.

Even if your peer supports them, your peer's peer might not.
Even for non-transitive attributes.
The best we can do is set them to 0, so nothing breaks.

--
Jakob Heitz.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Dickson
Sent: Monday, January 07, 2013 2:12 PM
To: John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

I have an open question, primarily intended for the folks "experimenting" across the Internet (and causing much excitement):

If there is even the slightest possibility of using some of these bits in future, REGARDLESS of for what, maybe the need to use them across unaware parties could be signalled/negotiated?

If negotiated, the unambiguous behavior of "pass unchanged" applies to the bits in question.

In any other case, any presumption about the bits getting through should not be made, and the current "MUST BE ZERO" should apply to all.

This would then mean, if NOT negotiated, allow any, but it is okay to stomp on them (but not required!!).

If the folks USING the bits really want to do more experiments and/or use them, a quick I-D on the new Capability would be nice, and I would support it.

While I would lean towards ALWAYS zeroing out the bits, I can see the argument the other way, and am fine with the current draft in LC, regardless of whether it is SHOULD or MUST.

Brian

On Mon, Jan 7, 2013 at 3:22 PM, John Leslie <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Shyam Sethuram <[email-masked]>
Date: Mon, 7 Jan 2013 16:50:01 -0800

Agree.
At best you can mandate "MUST propagate unchanged" for unrecognized
transitive attributes.
For recognized attributes, it would be upto the implementation to do what
it pleases -- this could
be based on attribute type for newer attributes (if at all).

shyam

On Mon, Jan 7, 2013 at 4:04 PM, Jakob Heitz <[email-masked]>wrote:

> **
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Brian
> Dickson
> *Sent:* Monday, January 07, 2013 2:12 PM
> *To:* John Leslie
> *Cc:* idr wg; John G. Scudder; Susan Hares
> *Subject:* Re: [Idr] 2 week WG adoption & LC on
> draft-hares-idr-update-attrib-low-bits-fix-00.
>
>  I have an open question, primarily intended for the folks
> "experimenting" across the Internet (and causing much excitement):
>
>  If there is even the slightest possibility of using some of these bits
> in future, REGARDLESS of for what, maybe the need to use them across
> unaware parties could be signalled/negotiated?
>
>  If the folks USING the bits really want to do more experiments and/or
> use them, a quick I-D on the new Capability would be nice, and I would
> support it.
>

---

From: <[email-masked]>
Date: Tue, 8 Jan 2013 08:53:04 +0000

Susan, John,

I support this draft (WG adoption & WG LC).

IMHO, it clarifies the original meaning of RFC 4271. (i.e. "when sent" meant when originated)

I'm not a big fan of the current §3. Known BGP Implementation Habits
- I would propose to move it to appendix.
- "Habits" sound strange to me. But I'll leave English language to others.
- IMHO the doc should clarify which behavior/habit is compliant with this document and which are not.
- From a protocol/IETF standpoint, do have a consensus that this draft is merely a clarification i.e. we are not changing the RFC 4271 spec? or not? If the former, those behaviors are not "habits" but non compliant implementations. This document is a clarification, so let's be clear. If the latter, may be the document should not call this a clarification but a re-specification of those bits.

I also agree with Chris, that we need to specify what is a propagation of an attribute vs a new (re)origination. E.g. if the value is changed, is this a propagation or an re-origination? I'm not sure I have an opinion on this. Eventually the draft could allow both. E.g. "SHOULD be propagated" (or re-originated, but a SHOULD rather than a MUST).

There had been a discussion about whether such clarification should be handled by a new draft or by an errata. What's the outcome / rule?

Thanks,
Regards,
Bruno

From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, January 07, 2013 8:31 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

Idr folks:

The draft name is:

gotten at :

Purpose is:

Comment early and often.

_________________________________________________________________________________________________________________________

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: t.petch <[email-masked]>
Date: Tue, 8 Jan 2013 15:39:42 +0000

----- Original Message -----
From: "John Leslie" <[email-masked]>
To: "Susan Hares" <[email-masked]>
Cc: "idr wg" <[email-masked]>; "'John G. Scudder'" <[email-masked]>
Sent: Monday, January 07, 2013 8:22 PM
> " attribute, it SHOULD propagate these flags as received.

Since we have two different ways of interpreting the current spec, any
nailing down of the spec is going to make some implementations
non-conforming; that is unavoidable.

Looking to the future, the underlying question is whether or not
we want to use the bits as optional transitive.

If we do, then they should be propagated as received and we can
have a progressive deployment of a new use.

If we do not, then they should be propagated as zero and we cannot
used them until all involved parties have been updated to understand
them.

So both approaches are right, depending on future use, and I do not
know which is the right 'right' answer.  SHOULD is a bit of a weasel
word here, allowing some fence sitting.

It seems a bit like fail-danger and fail-safe, more psychology than
technology.

Tom Petch

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 8 Jan 2013 11:10:59 -0500

Brian:

Interesting idea. 

The reason for the RFC rather the errata was to clarify when an
implementation supported this features. The capability extends my earlier
idea from something that can be tracked on contracts to a capability. 

Eventually, we'll have a set of RFCs that provide Errata on the 4271 text
with bits in this capability. The capability would signal on a peer basis
what errata you support. 

I write up the capability and send it to you.  

Sue 

From: Brian Dickson [mailto:[email-masked]] 
Sent: Monday, January 07, 2013 5:12 PM
To: John Leslie
Cc: Susan Hares; idr wg; John G. Scudder
Subject: Re: [Idr] 2 week WG adoption & LC on
draft-hares-idr-update-attrib-low-bits-fix-00.

In any other case, any presumption about the bits getting through should not
be made, and the current "MUST BE ZERO" should apply to all.

While I would lean towards ALWAYS zeroing out the bits, I can see the
argument the other way, and am fine with the current draft in LC, regardless
of whether it is SHOULD or MUST.

Brian

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 8 Jan 2013 11:51:11 -0500

Bruno:

Thank you for feedback on the support of the bits 

Having lived through all the revisions of BGP,  it was also my recollection
was that this was a clarification.  John’s memory matched mine. 

The reason for an RFC was to clearly draw a line when implementations engage
in enforcing this behavior.   Please also take a look at the idea of
capabilities signaling the specifics in error handling.  I’ll write-up the
draft on these issues. 

On paragraph 3 and habits - The discussion suggest I should consult  the
bgp-issues draft.  During the RFC4271 creation we had a long email thread
that Andrew Lange captured in a document (bgp-issues).  You may be able to
find an old copy of that draft.    My recollection is that we discussed
habits.  Let me review that text and get back to you. 

By the way, Stewart Bryant asked for a reformatting of that bgp-issues into
one or more of the different forms (short review, web page, and a clean-up
longer version).   I’ll try to “hurry” along that rewrite so we can review
it together. 

To clarify your question:

“what is a propagation of an attribute vs a new (re)origination. E.g. if the
value is changed, is this a propagation or an re-origination?”

John said: 

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

--------

I agree we also need to clear up what’s a propagation or a re-origination.
Are there some changes that you have operational concerns about (e.g.
2-byte/4byte AS changes, private AS stripping). 

Sue  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 08, 2013 3:53 AM
To: Susan Hares; 'John G. Scudder'
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC on
draft-hares-idr-update-attrib-low-bits-fix-00.

Susan, John,

IMHO, it clarifies the original meaning of RFC 4271. (i.e. "when sent" meant
when originated)

I’m not a big fan of the current §3. Known BGP Implementation Habits

- “Habits” sound strange to me. But I’ll leave English language to others.

- IMHO the doc should clarify which behavior/habit is compliant with this
document and which are not.

- From a protocol/IETF standpoint, do have a consensus that this draft is
merely a clarification i.e. we are not changing the RFC 4271 spec? or not?
If the former, those behaviors are not “habits” but non compliant
implementations. This document is a clarification, so let’s be clear. If the
latter, may be the document should not call this a clarification but a
re-specification of those bits.

I also agree with Chris, that we need to specify what is a propagation of an
attribute vs a new (re)origination. E.g. if the value is changed, is this a
propagation or an re-origination? I’m not sure I have an opinion on this.
Eventually the draft could allow both. E.g. “SHOULD be propagated” (or
re-originated, but a SHOULD rather than a MUST).

There had been a discussion about whether such clarification should be
handled by a new draft or by an errata. What’s the outcome / rule?

Thanks,

Regards,

Bruno

From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan
Hares
Sent: Monday, January 07, 2013 8:31 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] 2 week WG adoption & LC on
draft-hares-idr-update-attrib-low-bits-fix-00.

Idr folks: 

Because the mini-draft is so simple, we’re going to do a 

2 WG adoption and LC call combined.  If anyone objects, we’ll

The draft name is: 

gotten at :

 

Purpose is: 

Comment early and often.

____________________________________________________________________________
_____________________________________________
 
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: "Rob (William) Rice" <[email-masked]>
Date: Tue, 8 Jan 2013 17:47:56 +0000

I agree with Jakob.

Given that implementations exist that don't propagate these bits today, if you do update 4271, at what point would you be willing to define new flags and trust that all routers would propagate them properly? Given the ambiguity of the wording in 4271, it seems safer to signal any new behavior within the new attribute value.

Rob

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Monday, January 07, 2013 7:05 PM
To: Brian Dickson; John Leslie
Cc: idr wg; Susan Hares; John G. Scudder
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

--
Jakob Heitz.

Brian

---

From: <[email-masked]>
Date: Tue, 8 Jan 2013 17:54:10 +0000

Susan,

Thanks for your answer.

>From: Susan Hares [mailto:[email-masked]]
> I agree we also need to clear up what's a propagation or a re-origination.  Are there some changes that you have operational concerns about (e.g. 2-byte/4byte AS changes, private AS stripping).

Not that I can think of.
A priori, I was rather on the side of a clear and simple rule being totally unspecific: nothing specific on a per attribute basis, nor specific to the reason for changing the value of that attribute (including the handling of 2 different attributes(2-byte/4 byte) for the same data (as path). For example "propagation is re-advertising the attribute unchanged, as received. Anything else is re-origination" or the opposite POV: "Origination is adding a new non existing attribute to the route. Anything else is propagation"

Attributes which are a set of multiple values are tricky. e.g. when adding a community value in the community attribute:
- if I reset the bits, we lose the end to end propagation of the bits for the received communities
- if I keep the bits, I advertise my new community with specific bits that I may not be aware of their consequences.
Bruno

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, January 08, 2013 5:51 PM
To: DECRAENE Bruno OLNC/OLN; 'John G. Scudder'
Cc: 'idr wg'
Subject: RE: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

Bruno:

Having lived through all the revisions of BGP,  it was also my recollection was that this was a clarification.  John's memory matched mine.

The reason for an RFC was to clearly draw a line when implementations engage in enforcing this behavior.   Please also take a look at the idea of capabilities signaling the specifics in error handling.  I'll write-up the draft on these issues.

On paragraph 3 and habits - The discussion suggest I should consult  the bgp-issues draft.  During the RFC4271 creation we had a long email thread that Andrew Lange captured in a document (bgp-issues).  You may be able to find an old copy of that draft.    My recollection is that we discussed habits.  Let me review that text and get back to you.

By the way, Stewart Bryant asked for a reformatting of that bgp-issues into one or more of the different forms (short review, web page, and a clean-up longer version).   I'll try to "hurry" along that rewrite so we can review it together.

"what is a propagation of an attribute vs a new (re)origination. E.g. if the value is changed, is this a propagation or an re-origination?"

John said:
When a BGP speaker propagates an attribute, it MUST propagate these flags as received.
--------

I agree we also need to clear up what's a propagation or a re-origination.  Are there some changes that you have operational concerns about (e.g. 2-byte/4byte AS changes, private AS stripping).

Sue

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, January 08, 2013 3:53 AM
To: Susan Hares; 'John G. Scudder'
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

Susan, John,

Thanks,
Regards,
Bruno

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, January 07, 2013 8:31 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

Idr folks:

The draft name is:

gotten at :

Purpose is:

Comment early and often.

Thank you.

---

From: <[email-masked]>
Date: Tue, 8 Jan 2013 18:10:09 +0000

> It's too late. Those bits are dead.

I don't see how this is different from deprecating/retiring and reusing a code point. Is there an existing IETF way for this? http://tools.ietf.org/html/draft-kompella-mpls-special-purpose-labels-01#section-3.2 is discussing this in the MPLS WG. Should this be a topic for next routing area meeting?

I'm not sure why this would be too late. Some time may be needed before (re)using them but I don't see why this should stop us from deprecating existing "use" (actually existing non use/mess).

> at what point would you be willing to define new flags and trust that all routers would propagate them properly?
I don't know but it looks like an issue for the one willing to reuse those bits, not for the ones deprecating/clearing its current use.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob (William) Rice
Sent: Tuesday, January 08, 2013 6:48 PM
To: Jakob Heitz; Brian Dickson; John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

I agree with Jakob.

Rob

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jakob Heitz

--
Jakob Heitz.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Dickson

Brian

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 8 Jan 2013 18:25:27 +0000

The only thing I will do is ignore on receipt and set to 0 on send.
Anything else risks causing a session reset. It's not worth it.

--
Jakob Heitz.

> It's too late. Those bits are dead.

I don’t see how this is different from deprecating/retiring and reusing a code point. Is there an existing IETF way for this? http://tools.ietf.org/html/draft-kompella-mpls-special-purpose-labels-01#section-3.2 is discussing this in the MPLS WG. Should this be a topic for next routing area meeting?

I’m not sure why this would be too late. Some time may be needed before (re)using them but I don’t see why this should stop us from deprecating existing “use” (actually existing non use/mess).

> at what point would you be willing to define new flags and trust that all routers would propagate them properly?
I don’t know but it looks like an issue for the one willing to reuse those bits, not for the ones deprecating/clearing its current use.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Rob (William) Rice

I agree with Jakob.

Given that implementations exist that don’t propagate these bits today, if you do update 4271, at what point would you be willing to define new flags and trust that all routers would propagate them properly? Given the ambiguity of the wording in 4271, it seems safer to signal any new behavior within the new attribute value.

Rob

--
Jakob Heitz.

Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 08 Jan 2013 13:44:12 -0600

> It seems a bit like fail-danger and fail-safe, more psychology than

I agree we need to pick one approach or the other, and it should be 
either "MUST propagate as received", or "MUST propagate as zero".  The 
SHOULD option is essentially what we have now and really won't fix the 
issue one way or the other.   If we want to go the SHOULD route, I'd 
prefer we just add "When received, any value MUST be accepted" as a 
simple errata.

I prefer the "MUST propagate as received" option personally.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 8 Jan 2013 19:51:54 +0000

> I agree we need to pick one approach or the other, and it should be either "MUST propagate as received", or "MUST propagate as zero".  The SHOULD option is essentially what we have now and really won't fix the issue one way or the other.   If we want to go the SHOULD route, I'd prefer we just add "When received, any value MUST be accepted" as a simple errata.
> 

That would work if bgp were new. But it's not.
Anything other than "MUST propagate as zero" risks a session reset. I won't do that.

--
Jakob Heitz.

---

From: <[email-masked]>
Date: Wed, 9 Jan 2013 14:05:14 +0000

> The only thing I will do is ignore on receipt and set to 0 on send.

I think I understand your point from an implementation/product point of view. (yet, I’m wondering if you also changed your implementation to accommodate others bugs. E.g. errors on the extended length bit. And IMHO the good answer is rather to allow the SP to filter out an update/attribute based on any data in the update message (including unused field as we see).

However, from a standardization standpoint, IMO we should not change/define standard based on bugs in one implementation.

Because if we refer to the same issue “Reception of a set bit in the lower−order four bits of the Attribute Flags octet in a BGP update will cause the BGP session to reset.”, this is a bug and RFC 4271 was crystal clear on this point “MUST be ignored when received”.

So I still support WG adoption because I believe spec clarity is a good thing.

That being said, you have a point on deployment. So given that:

a) more work is needed on the draft to clarify the action/definition of an attribute propagation

b) IDR policy request 2 implementations of draft in order to avoid potential risk in deployments in a critical infrastructure, while here there is a known risk when deploying.

I now tend to believe that this draft is not yet ready for RFC publication. Hence I withdraw my support for WG LC until the technical point (a) is clarified and that we believe deployed buggy versions have been replaced (or whatever rule the IETF/WG has for code point reuse).

Bruno

From: Jakob Heitz [mailto:[email-masked]]
Sent: Tuesday, January 08, 2013 7:25 PM
To: DECRAENE Bruno OLNC/OLN
Cc: Rob (William) Rice; Brian Dickson; John Leslie; idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00.

--
Jakob Heitz.

I agree with Jakob.

Rob

--
Jakob Heitz.

Brian

Thank you.

---

From: David Farmer <[email-masked]>
Date: Mon, 28 Jan 2013 14:33:46 -0600

> Anything other than "MUST propagate as zero" risks a session reset. I won't do that.

I've been thinking about this issue for a bit, and would like to suggest 
a compromise; all implementations should provide "propagated as 
received" at least as an option and "propagate as zero" should be the 
only other allowed behavior.  I propose something like the following text;

    SHOULD propagate as received. If not propagated as received, then
    MUST propagate as zero and provide a configuration option to
    propagate as received.

This way all implementations are able to "propagate as received", it 
only becomes an issue of the default behavior an implementation chooses. 
  With the recommended behavior being "propagate as received", and 
"propagate as zero" being the only other allowed behavior.

There should also be additional discussion of the following;

1. As the "when received, any value MUST be accepted" clause is 
implemented more universally, implementations that choose "propagate as 
zero" as their default behavior should reconsider "propagate as 
received" as their default behavior.

2. That implementation that chose the recommended "propagate as 
received" should also consider a per-peer configuration option to 
"propagate as zero" for interoperability with older implementations that 
are known NOT to conform with the "when received, any value MUST be 
accepted" clause.

This creates a knob, and I really don't like that, but honestly there 
are implementations that DO NOT conform with the "when received, any 
value MUST be accepted" clause, and we have to deal with, at least for 
now.  So, while I think creating knobs should be avoided, I'm not sure 
it can realistically be avoided in this case, and with the 
implementations that are in the wild today.

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 28 Jan 2013 20:03:46 -0500

On Mon, Jan 28, 2013 at 3:33 PM, David Farmer <[email-masked]> wrote:
> This creates a knob, and I really don't like that, but honestly there are
> implementations that DO NOT conform with the "when received, any value MUST
> be accepted" clause, and we have to deal with, at least for now.  So, while
> I think creating knobs should be avoided, I'm not sure it can realistically
> be avoided in this case, and with the implementations that are in the wild
> today.

I always like options/knobs but I doubt your suggestion will be popular.

Why do you think propagate-as-received should be the default behavior?

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

---

From: David Farmer <[email-masked]>
Date: Mon, 28 Jan 2013 19:30:50 -0600

> Why do you think propagate-as-received should be the default behavior?

The argument is in the intro of the draft;

    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.

The compromise is require all conforming implementations to at least 
support propagate-as-received as an option.  It doesn't completely 
eliminate the issue described in the intro, but at least there is still 
some minimal hope of being able to implement new flags some day. 
Especially, since it should be clear that propagate-as-zero is really 
just a transition, and maybe in some future revision it could be removed 
once any-value-MUST-be-accepted is more or less universally implemented. 
One can hope, at least I link that better than "the bits are dead".

What do others think?