Subject: [Idr] One week extension to WGLC for draft-ietf-idr-large-community

From: "John G. Scudder" <[email-masked]>
Date: Mon, 14 Nov 2016 18:10:59 +0900

Hi All,

We originally WGLC'd -03. The document is now at -08 as a result of WGLC, RTG-DIR and Document Shepherd review comments. Most of the changes are editorial but there are a couple that rise beyond that level, and I would like to call the WG's attention to them. The ones I've identified are:

1. Canonical Representation. -08 specifies that the fields SHOULD be colon-separated. -03 did not.

If anyone has an objection to this change, that was not already discussed when it was first proposed/introduced, now's the time to raise it. Please don't reiterate a comment that was already discussed. (Consensus so far supports the change.)

2. Duplicate values. -03 used SHOULD:

   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
   receiving speaker SHOULD silently remove duplicate BGP Large
   Community values from a BGP Large Community attribute.

-08 uses MUST:

   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove duplicate BGP Large
   Community values from a BGP Large Community attribute.

This is a new change made at the suggestion of the Document Shepherd (that is, me). If anyone has an objection, please raise it.

Other than that, the rest of the changes are editorial and shouldn't be controversial AFAICT. If you disagree, please explain why.

The rfcdiff from -03 to -08:

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-idr-large-community-03.txt&url2=https://tools.ietf.org/id/draft-ietf-idr-large-community-08.txt

Please raise any objections by November 21. In this case, silence will be taken as consent assuming you've already supported publication.

Thanks,

--John

---

From: Peter Hessler <[email-masked]>
Date: Mon, 14 Nov 2016 10:23:38 +0100

On 2016 Nov 14 (Mon) at 18:10:59 +0900 (+0900), John G. Scudder wrote:
:Hi All,
:
:We originally WGLC'd -03. The document is now at -08 as a result of WGLC, RTG-DIR and Document Shepherd review comments. Most of the changes are editorial but there are a couple that rise beyond that level, and I would like to call the WG's attention to them. The ones I've identified are:
:
:1. Canonical Representation. -08 specifies that the fields SHOULD be colon-separated. -03 did not.
:
:If anyone has an objection to this change, that was not already discussed when it was first proposed/introduced, now's the time to raise it. Please don't reiterate a comment that was already discussed. (Consensus so far supports the change.)
:

I support this.

:2. Duplicate values. -03 used SHOULD:
:
:   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
:   receiving speaker SHOULD silently remove duplicate BGP Large
:   Community values from a BGP Large Community attribute.
:
:-08 uses MUST:
:
:   Duplicate BGP Large Community values MUST NOT be transmitted.  A
:   receiving speaker MUST silently remove duplicate BGP Large
:   Community values from a BGP Large Community attribute.
:
:This is a new change made at the suggestion of the Document Shepherd (that is, me). If anyone has an objection, please raise it.
:

I object.

RFC 1997 and 4360 communities have no such restrictions.  Why should
Large have them?

I would prefer leaving them as SHOULD NOT, or dropping that paragraph.

:Other than that, the rest of the changes are editorial and shouldn't be controversial AFAICT. If you disagree, please explain why.
:

With the exception of the duplicate values issue noted above, I support
the draft.

:The rfcdiff from -03 to -08:
:
:https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-idr-large-community-03.txt&url2=https://tools.ietf.org/id/draft-ietf-idr-large-community-08.txt
:
:Please raise any objections by November 21. In this case, silence will be taken as consent assuming you've already supported publication.
:
:Thanks,
:
:--John

-- 
"MacDonald has the gift on compressing the largest amount of words into
the smallest amount of thoughts."
		-- Winston Churchill

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 14 Nov 2016 21:22:45 +0900

Writing solely in my role as a WG contributor:

On Nov 14, 2016, at 6:23 PM, Peter Hessler <[email-masked]> wrote:
> RFC 1997 and 4360 communities have no such restrictions.  

I assume you're not talking about the deduplication requirement itself, since that already was discussed and went through WGLC. I'm reading your "such restrictions" as relating specifically to the change from the less-restrictive SHOULD to the more-restrictive MUST, and that's what I'm addressing here.

> Why should

For clarity. RFC 1997 doesn't even have RFC 2119 keywords (of course). That doesn't justify omitting them from Large. Similar principle applies.

> I would prefer leaving them as SHOULD NOT, or dropping that paragraph.

In writing and reviewing documents, when I see a "SHOULD NOT" I generally try to ask the question implied by its RFC 2119 definition:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

So, if the authors choose SHOULD NOT, it means they (or the WG consensus) believe "valid reasons in particular circumstances when the particular behavior is acceptable or even useful".

In thinking about this one, I haven't come up with a plausible, non-contrived reason or circumstance when duplicate large communities would be useful. This is especially true since even if one came up with some clever hack that involved sending dups, one couldn't count on them being received (since most implementations could be assumed to follow the "silently remove" clause) and certainly couldn't count on them being propagated. That being the case, RFC 2119 suggests MUST NOT is appropriate. This makes the spec easier to implement -- if an implementor sees MUST NOT, the document isn't asking them to pause and consider their options. If they see SHOULD NOT, the document is subtly (or not so subtly) implying that they'd better stop and think about the consequences of following, or not following, the relevant clause. 

I'll also point out that the text (whether with SHOULD NOT or MUST NOT) embodies Postel's law.

I will concede up front that narrowly-construed, transmission or propagation of duplicate large community values is "acceptable" insofar as it would be unlikely to cause any serious harm. However, I'll be interested to hear if you have in mind a "valid reason in particular circumstances when [this] behavior is ... useful". Because if there's no reasonable expectation it would ever be useful, I see no reason to make the spec even marginally more complex to accommodate it.

I don't see a downside to making the change (well, obviously, or I wouldn't have suggested it) and I do see an upside, namely that it makes the spec easier to implement. 

Regards,

--John

---

From: Peter Hessler <[email-masked]>
Date: Mon, 14 Nov 2016 17:17:58 +0100

On 2016 Nov 14 (Mon) at 10:23:38 +0100 (+0100), Peter Hessler wrote:
:On 2016 Nov 14 (Mon) at 18:10:59 +0900 (+0900), John G. Scudder wrote:
::2. Duplicate values. -03 used SHOULD:
::
::   Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
::   receiving speaker SHOULD silently remove duplicate BGP Large
::   Community values from a BGP Large Community attribute.
::
::-08 uses MUST:
::
::   Duplicate BGP Large Community values MUST NOT be transmitted.  A
::   receiving speaker MUST silently remove duplicate BGP Large
::   Community values from a BGP Large Community attribute.
::
::This is a new change made at the suggestion of the Document Shepherd (that is, me). If anyone has an objection, please raise it.
::
:
:I object.
:
:RFC 1997 and 4360 communities have no such restrictions.  Why should
:Large have them?
:
:I would prefer leaving them as SHOULD NOT, or dropping that paragraph.
:

After the discussions from John, Danny, and Job; I withdraw my
objection.

-- 
No violence, gentlemen -- no violence, I beg of you! Consider
the furniture!
		-- Sherlock Holmes

---

From: Sander Steffann <[email-masked]>
Date: Mon, 14 Nov 2016 17:18:05 +0100

Hi John,

> Op 14 nov. 2016, om 13:22 heeft John G. Scudder <[email-masked]> het volgende geschreven:
> 
> In thinking about this one, I haven't come up with a plausible, non-contrived reason or circumstance when duplicate large communities would be useful.

Useful: no, but acceptable: maybe, as you write below.

> This is especially true since even if one came up with some clever hack that involved sending dups, one couldn't count on them being received (since most implementations could be assumed to follow the "silently remove" clause) and certainly couldn't count on them being propagated. That being the case, RFC 2119 suggests MUST NOT is appropriate. This makes the spec easier to implement -- if an implementor sees MUST NOT, the document isn't asking them to pause and consider their options. If they see SHOULD NOT, the document is subtly (or not so subtly) implying that they'd better stop and think about the consequences of following, or not following, the relevant clause.

The MUST/MUST NOT wording makes it mandatory for a router to evaluate the communities to make sure there are no duplicates. A router that just forwards the attribute (it doesn't know about large or it doesn't care) might have a reason to not inspect and validate them. It should never receive them in the first place of course, but you never know what strange stuff you receive :)

Based on this I think SHOULD is better than MUST: it allows routers to forward the attribute as received without spending cycles on evaluating it if they don't want/need to. It also aligns better with the behaviour of routers that don't understand the large attribute at all.

Cheers,
Sander

---

From: Adam Chappell <[email-masked]>
Date: Mon, 14 Nov 2016 17:50:42 +0100

Hi John, all.

>    Community values from a BGP Large Community attribute.
Regardless of 2119 language, perhaps it might be more useful to tackle the
duplication issue again on the Postel front, especially because of the
opaque-ness through non-aware implementations which certainly won't weed
out dupes between misbehaving implementations.

I think that we really want an implementation to not send duplicates, but
tolerate receiving them with no ill effect. Certainly not to encourage
dupes to have meaning. But we also want to make it easy to implement
correctly, and hard to mess up.

Maybe it is better to state the idempotence property that we expect (and
that I saw in the other window that Job just outlined) in section 2
explicitly. Eg.

"
This document defines the BGP Large Communities attribute as an
optional transitive path attribute of variable length. A route carrying a
BGP Large Communities attribute is idempotently associated with the
community indicated in the attribute.
"

This together with the clear statement that community ordering is not
significant and that duplicates should not be transmitted offers a broad
hint to a lazy implementor that communities could be stored in a
set/map/hash, rather than a list/array to achieve the right behaviour.

Let's not require a receiver to take any special action in order to
sanitise/cleanse received attributes. At least not more than he would
already need to do for his own operation.

-- Adam.

---

From: Adam Chappell <[email-masked]>
Date: Mon, 14 Nov 2016 17:55:09 +0100

> set/map/hash, rather than a list/array to achieve the right behaviour.

Aargh - "duplicates MUST NOT be transmitted" that should have read. Sorry
for the confusion.

-- Adam.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 15 Nov 2016 03:42:05 +0900

Remember that the attribute is transitive optional. This means that it's completely valid per RFC 4271 S. 5 for a router that doesn't implement the spec to receive and transmit the attribute without scrubbing it, no matter what instructions we provide in the spec. So --

On Nov 15, 2016, at 1:18 AM, Sander Steffann <[email-masked]> wrote:
> The MUST/MUST NOT wording makes it mandatory for a router

Implicitly, a router that implements the large communities spec. It's not necessary to call this out explicitly in the large comms spec since RFC 4271 covers the case explicitly: "It is not required or expected that all BGP implementations support all optional attributes."

> to evaluate the communities to make sure there are no duplicates. A router that just forwards the attribute (it doesn't know about large or it doesn't care)

The "doesn't care" case implies an implementation that has large comms code but is configured to pretend it doesn't; the feature is present but disabled. This distinction is admittedly a little unclear in RFC 4271 but IMO it's fine for a router to pretend to fall into the "I don't support this attribute" case, if for some reason it needs to, as long as it behaves consistently according to that pretense. Basically this comes down to what "support" means in the sentence I quoted above -- does it mean the code is present? Or does it mean the code path is present and enabled in configuration? I'm fine with the latter and in my experience this is the common interpretation. (I think this nuance is well beyond the scope of the present draft to fix, in any case.)

> might have a reason to not inspect and validate them. It should never receive them in the first place of course,

On the contrary, it's in the nature of transitive optional attributes that it's normal to receive and propagate them.

> but you never know what strange stuff you receive :)
> 

As discussed above, in my opinion MUST is completely consistent with the behaviour of routers that don't understand the large attribute at all.

Regards,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 15 Nov 2016 03:49:50 +0900

In my role as co-chair:

> Please raise any objections by November 21. In this case, silence will be taken as consent assuming you've already supported publication.

Given there's debate regarding the SHOULD/MUST change, I think it's not appropriate to assume silence gives consent to the change. So, I take that back and expect we will judge consensus for this item in the usual way. (The same would apply to the canonical representation item if there were to be debate about it.)

--John

---

From: Brian Dickson <[email-masked]>
Date: Mon, 14 Nov 2016 11:24:01 -0800

On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder <[email-masked]> wrote:

> > Please raise any objections by November 21. In this case, silence will
> be taken as consent assuming you've already supported publication.
>
> Given there's debate regarding the SHOULD/MUST change, I think it's not
> appropriate to assume silence gives consent to the change. So, I take that
> back and expect we will judge consensus for this item in the usual way.
> (The same would apply to the canonical representation item if there were to
> be debate about it.)

I have read and reviewed the document, and believe it is ready to go.
I support its publication in the -08 revision.

(And just to be clear, I have withdrawn any/all objections on previous
versions, this one is exactly right.)

Brian Dickson

P.S. One of the author's email addresses appears to be broken -- Keyur
Patel's email domain, arrcus.com, appears not to be registered.

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 21:39:42 +0000

John, Sue,

 > From: Idr [mailto:[email-masked]] On Behalf Of John G. Scudder  > Sent: Monday, November 14, 2016 7:50 PM
> 
 > In my role as co-chair:
 > 
 > > Please raise any objections by November 21. In this case, silence will be taken as
 > consent assuming you've already supported publication.
 > 
 > Given there's debate regarding the SHOULD/MUST change, I think it's not appropriate to
 > assume silence gives consent to the change. So, I take that back and expect we will judge
 > consensus for this item in the usual way. 

1) I support the "MUST".
In addition to the reasons already provided, IMHO, I would say that this also seems aligned with RFC 7606. (but I would prefer not to re-open the 7606 error handling debate).

2) If "MUST" is kept, on a side note, 

- I'm less sure about the "silently" part of "MUST silently" as I'm not sure why logging the error should be considered as a protocol violation. (and 7606 was rather calling for logging the error). So I would propose to remove "silently.

- If we now have ' Duplicate BGP Large Community values MUST NOT be transmitted.', receiving a duplicate is a clear protocol error. In the general case, it's difficult to know whether the error is on the sending side or the receiving side. (Although the receiving side will typically consider that he is (obviously always) right, hence the sender must be in error). Given that large community has an impact on route preference or selection, this may call for "treat-as-withdraw"...
I already hear the objection that "both value are the same hence it has no influence", but it's the receiver which claims that both value are the same. If the error is on the receiving side, possibly both values were sent as different. (e.g. oops, the test was only considering the first 64 bits. And the error had never been detected so far, because the first 64 bits had been different during testing, or the duplicate silently removed))

--Bruno

> (The same would apply to the canonical
 > representation item if there were to be debate about it.)
 > 
 > --John
 > _______________________________________________
 > Idr mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: heasley <[email-masked]>
Date: Mon, 14 Nov 2016 22:59:44 +0000

> Given there's debate regarding the SHOULD/MUST change, I think it's not appropriate to assume silence gives consent to the change. So, I take that back and expect we will judge consensus for this i…

I agree with your analysis of the keywords and thank you for your replies in  
this debate.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 14 Nov 2016 22:59:47 +0000

Receipt of a duplicate MUST NOT trigger any error handling. It is not a protocol error. It MUST NOT cause treat-as-withdraw and MUST NOT cause attribute discard. Simply deleting the duplicate is enough. Even a log of the deletion is noise. Log it if you must, but my code does not. This is consistent with legacy community handling.

Therefore, I support SHOULD.

Thanks,
Jakob.

> On Nov 15, 2016, at 6:39 AM, "[email-masked]" <[email-masked]> wrote:
> 
> John, Sue,
>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 15 Nov 2016 08:04:52 +0900

On 11/15/16 4:24 AM, Brian Dickson wrote:
> 
> 
> On Mon, Nov 14, 2016 at 10:49 AM, John G. Scudder <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     In my role as co-chair:
> 
>     On Nov 14, 2016, at 6:10 PM, John G. Scudder <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     Given there's debate regarding the SHOULD/MUST change, I think it's
>     not appropriate to assume silence gives consent to the change. So, I
>     take that back and expect we will judge consensus for this item in
>     the usual way. (The same would apply to the canonical representation
>     item if there were to be debate about it.)
> 
> 
> Patel's email domain, arrcus.com <http://arrcus.com>, appears not to be
> registered. 

[email-masked]

J@mb:~$host arrcus.com
arrcus.com has address 50.63.202.51
arrcus.com mail is handled by 10 mx1-us1.ppe-hosted.com.
arrcus.com mail is handled by 20 mx2-us1.ppe-hosted.com.

he responds to email there...

not everything is a webserver

---

From: Keyur Patel <[email-masked]>
Date: Mon, 14 Nov 2016 23:09:27 +0000

Thanks Joel. [?]

Hi Brian,

I did send you an offline email asking for clarification. [?]

Regards,

Keyur

________________________________
From: joel jaeggli <[email-masked]>
Sent: Monday, November 14, 2016 3:04:52 PM
To: Brian Dickson; John G. Scudder
Cc: IETF IDR; Keyur Patel
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community

[email-masked]

J@mb:~$host arrcus.com

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 15 Nov 2016 08:15:21 +0900

FWIW I think your concerns are still addressed if the MUST language is used. They would apply if the change implied by Bruno's final bullet were to be adopted.

For my own part (again, in my role as a WG contributor) 

- I think Bruno's point about the -08 language appearing to forbid logging is well-taken, and I would support fixing it, for example by dropping the word "silently". A sentence like "In case such a duplicate Large Community is received an error MAY be logged" could be added if wanted (the "or may not" branch is implicit) but personally I'd opt for just dropping "silently" and leaving it to implementor discretion as we already do for a plethora of other things.

- Although I take Bruno's point about it being a protocol error, I would not support the change implied in the final bullet, and would prefer the text as written, modulo dropping "silently". Also, changing the text back to SHOULD wouldn't really address Bruno's concern anyhow, except in a spec-lawyer kind of way, IMO.

Thanks,

--John

---

From: Sander Steffann <[email-masked]>
Date: Tue, 15 Nov 2016 00:36:07 +0100

Hi John,

> The "doesn't care" case implies an implementation that has large comms code but is configured to pretend it doesn't; the feature is present but disabled. This distinction is admittedly a little unc…

That covers the case I worried about then :)

> On the contrary, it's in the nature of transitive optional attributes that it's normal to receive and propagate them.

I meant large attributes that contain duplicate community values.

> As discussed above, in my opinion MUST is completely consistent with the behaviour of routers that don't understand the large attribute at all.

If an implementation is allowed to forward the attribute as-is without looking at it (code path present but disabled, treating it as an unknown optional transitive attribute) then I'm fine with that.

Please count me as neutral on the issue. I'm fine with either wording, I just wanted to make sure this wouldn't cause problems.

Cheers,
Sander

---

From: Brian Dickson <[email-masked]>
Date: Mon, 14 Nov 2016 15:40:51 -0800

On Mon, Nov 14, 2016 at 3:04 PM, joel jaeggli <[email-masked]> wrote:

> >     > Please raise any objections by November 21. In this case, silence
> will be taken as consent assuming you've already supported publication.
> >

Sorry, my bad.
(I was curious about what Keyur is up to, which lead to the wrong
conclusion.)

Brian

---

From: Jared Mauch <[email-masked]>
Date: Mon, 14 Nov 2016 18:51:25 -0500

> On Nov 14, 2016, at 6:15 PM, John G. Scudder <[email-masked]> wrote:
> 

I think simply saying duplicates are not errors is sufficient.  I don’t think the SHOULD/MUST discussion merits a lot of bits typed as it’s unlikely to have a real impact.  

Due to the opaque nature of the attribute, it seems SHOULD NOT is enough.  Saying it should be ignored/dropped seems a step beyond that is necessary to describe in the protocol standard.  The same is true for the logging prohibition, that is an operational aspect of the routing platform or implementation vs a protocol issue, which should not be addressed here and is therefore out of scope.  Simply stating it is not an error should be sufficient.

I do understand the desire to not send duplicates, and agree implementors SHOULD NOT and MUST take care to not send them, but software is imperfect and we should ensure the least disruption feasible.  This was the point behind RFC7606 to provide safe degradation of BGP speakers.

- Jared (hopefully my only comment on the thread)

---

From: <[email-masked]>
Date: Tue, 15 Nov 2016 13:46:15 +0000

TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'm not fine with -06, unless some text is added, because it may open different interpretation.

> From: Jakob Heitz (jheitz) [mailto:[email-masked]]  > Sent: Tuesday, November 15, 2016 12:00 AM
> 
 > Receipt of a duplicate MUST NOT trigger any error handling. It is not a protocol error. It
 > MUST NOT cause treat-as-withdraw and MUST NOT cause attribute discard. Simply
 > deleting the duplicate is enough. Even a log of the deletion is noise. Log it if you must, but
 > my code does not. This is consistent with legacy community handling.
 > 

If you believe that this is not an error, there is no need for specific action, not to mention trying to correct the .... error. ("SHOULD remove the duplicate" is trying to correct it).

Taking a step back, I think that what we really must specify, is whether a community received N times, MUST be considered as received N times or 1 time, because this impacts the meaning, hence the interop. e.g. if the community means prepend one, does sending it N times means prepend N or prepend 1)
>From the current text, it seems that people want to only have the community interpreted once. (which is a restriction of what we could do).

If so, it seems to never make sense to send the same value multiple times. So it seems clearer to completely forbid it (MUST NOT) rather than leaving the option to re-open the discussion latter or consider how the receiver need to react to "keep the meaning" intended by the originator. Especially since some combination seems to make less sense. e.g. "SHOULD NOT be sent, SHOULD be removed" where we are opening the option to send duplicate, but we don't define how such duplicate will propagate, so the originator has even less reason to try an innovative unspecified behavior.

Now, if we have "MUST NOT be sent", then I think that this is an error condition if we receive duplicate. And I see 3 options:
a) leave them all, (i.e. no correction) but specify that N times as the same value that 1 time.
b) try to stop the error, by correcting it (i.e. "remove duplicate") but that seem to assume that the error is on the sending side, while the error could in fact be on the receiving side. It's bothers me a little that this point had never been discussed by the WG, especially since for the receiver (coder), there is a clear bias in favor of trusting itself (himself). While we had real world example where the error was on the receiving side or at least not on the sending side (e.g. error due to code point collision, e.g. VPN extended community 0x010a, and more recently attributes in draft-ietf-idr-deprecate-30-31-129)
c) try to stop the error, with no assumption on the source of the error, by withdrawing the error (Attribute discard or Treat-As-Withdraw). Would be TAW in our case.

I had suggested "treat-as-withdraw" as a provocation to trigger the discussion, which had never happened. But personally I don't care much on the action, provided that the interpretation is not ambiguous. e.g. MUST be considered as received 1 time.

Again, I fine with latest version (-08). I'm less fine with the -06 version, especially as the behavior on the receiving side is not strictly defined and may not be interoperable (-06 allows keeping duplicate while not defining its meaning)

Thanks,
--Bruno
 
 > > In addition to the reasons already provided, IMHO, I would say that this also seems
 > aligned with RFC 7606. (but I would prefer not to re-open the 7606 error handling debate).
 > >
 > > - I'm less sure about the "silently" part of "MUST silently" as I'm not sure why logging
 > the error should be considered as a protocol violation. (and 7606 was rather calling for
 > logging the error). So I would propose to remove "silently.
 > >
 > > - If we now have ' Duplicate BGP Large Community values MUST NOT be transmitted.',
 > receiving a duplicate is a clear protocol error. In the general case, it's difficult to know
 > whether the error is on the sending side or the receiving side. (Although the receiving side
 > will typically consider that he is (obviously always) right, hence the sender must be in
 > error). Given that large community has an impact on route preference or selection, this
 > may call for "treat-as-withdraw"...
 > > I already hear the objection that "both value are the same hence it has no influence",
 > but it's the receiver which claims that both value are the same. If the error is on the
 > receiving side, possibly both values were sent as different. (e.g. oops, the test was only
 > considering the first 64 bits. And the error had never been detected so far, because the
 > first 64 bits had been different during testing, or the duplicate silently removed))
 > >
 > > --Bruno
 > >
 > _________________________________________________________________________
 > ________________________________________________
 > >

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 15 Nov 2016 15:19:22 +0100

Hi Bruno,

Since I was going to ask the same question let me provide an example:

AS1 ---- AS2 ---- AS3 ---- peer_X

AS3 publishes community with action if I receive this community I will
PREPEND my AS# one time towards my peer X.

Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for
perhaps completely different reason also comes up with idea to hint AS3 to
execute prepend on the same very prefix P.

So AS3 is receiving the two communities which both are valid and truely
intended. Why we would drop it ?

I admit when the topic came up originally the major concern to me was to
prevent stuffing community with N identical sets of values by same AS.

But even this case can be legitimate. Let's consider that said AS2  needs
prepend by 2 to some prefixes and AS3 offers *only* community of single
PREPEND. Why not adding it twice to such selected prefixes not be a way to
signal such requirement ?

Regards,
R.

On Nov 15, 2016 10:46 PM, <[email-masked]> wrote:

> TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'm not fine
> with -06, unless some text is added, because it may open different
> interpretation.
>
> If you believe that this is not an error, there is no need for specific
> action, not to mention trying to correct the .... error. ("SHOULD remove
> the duplicate" is trying to correct it).
>
> Taking a step back, I think that what we really must specify, is whether a
> community received N times, MUST be considered as received N times or 1
> time, because this impacts the meaning, hence the interop. e.g. if the
> community means prepend one, does sending it N times means prepend N or
> prepend 1)
> >From the current text, it seems that people want to only have the
> community interpreted once. (which is a restriction of what we could do).
>
> If so, it seems to never make sense to send the same value multiple times.
> So it seems clearer to completely forbid it (MUST NOT) rather than leaving
> the option to re-open the discussion latter or consider how the receiver
> need to react to "keep the meaning" intended by the originator. Especially
> since some combination seems to make less sense. e.g. "SHOULD NOT be sent,
> SHOULD be removed" where we are opening the option to send duplicate, but
> we don't define how such duplicate will propagate, so the originator has
> even less reason to try an innovative unspecified behavior.
>
> Now, if we have "MUST NOT be sent", then I think that this is an error
> condition if we receive duplicate. And I see 3 options:
> b) try to stop the error, by correcting it (i.e. "remove duplicate") but
> that seem to assume that the error is on the sending side, while the error
> could in fact be on the receiving side. It's bothers me a little that this
> point had never been discussed by the WG, especially since for the receiver
> (coder), there is a clear bias in favor of trusting itself (himself). While
> we had real world example where the error was on the receiving side or at
> least not on the sending side (e.g. error due to code point collision, e.g.
> VPN extended community 0x010a, and more recently attributes in
> draft-ietf-idr-deprecate-30-31-129)
> c) try to stop the error, with no assumption on the source of the error,
> by withdrawing the error (Attribute discard or Treat-As-Withdraw). Would be
> TAW in our case.
>
> I had suggested "treat-as-withdraw" as a provocation to trigger the
> discussion, which had never happened. But personally I don't care much on
> the action, provided that the interpretation is not ambiguous. e.g. MUST be
> considered as received 1 time.
>
> Again, I fine with latest version (-08). I'm less fine with the -06
> version, especially as the behavior on the receiving side is not strictly
> defined and may not be interoperable (-06 allows keeping duplicate while
> not defining its meaning)
>
> Thanks,
> --Bruno
>
>  > Thanks,
>  > Jakob.
>  >
>  >
>  > >> From: Idr [mailto:[email-masked]] On Behalf Of John G.
> Scudder  > Sent: Monday,
>  > November 14, 2016 7:50 PM
>  > >>
>  > >> In my role as co-chair:
>  > >>
> will be taken as
> not appropriate
>  > to
>  > >> assume silence gives consent to the change. So, I take that back and
> expect we will
>  > judge
>  > > 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,
>  > > 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;
>  > > If you have received this email in error, please notify the sender
> and delete this
>  > message and its attachments.
>  > > As emails may be altered, Orange is not liable for messages that have
> been modified,
>  > changed or falsified.
>  > > Thank you.
>  > >
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Tue, 15 Nov 2016 15:28:32 +0100

Hi Robert,

Route-maps don't work that way in today's router software, every clause
is evaluated once and then the route-map execution either stops (if no
continue statement is given) or proceeds to the next clause (if a
continue statement is given). Either way, the community will only be
matched once even if it's been tagged twice on the same prefix.

Best regards,
Martijn

On 11/15/2016 03:19 PM, Robert Raszuk wrote:
> Now AS1 comes with a need for such prepend on PI prefix P. Then AS2
> for perhaps completely different reason also comes up with idea to
> hint AS3 to execute prepend on the same very prefix P.
>
> So AS3 is receiving the two communities which both are valid and
> truely intended. Why we would drop it ?
>
> I admit when the topic came up originally the major concern to me was
> to prevent stuffing community with N identical sets of values by same AS.
>
> But even this case can be legitimate. Let's consider that said AS2 
> needs prepend by 2 to some prefixes and AS3 offers *only* community of
> single PREPEND. Why not adding it twice to such selected prefixes not
> be a way to signal such requirement ?
>
> Regards,
> R.
>
>
> On Nov 15, 2016 10:46 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     TL;DR: I'm fine with -08 (MUST NOT send, MUST de-duplicate). I'm
>     not fine with -06, unless some text is added, because it may open
>     different interpretation.
>
>     > From: Jakob Heitz (jheitz) [mailto:[email-masked]
>     <mailto:[email-masked]>]  > Sent: Tuesday, November 15, 2016
>     12:00 AM
>     >
>     If you believe that this is not an error, there is no need for
>     specific action, not to mention trying to correct the .... error.
>     ("SHOULD remove the duplicate" is trying to correct it).
>
>     Taking a step back, I think that what we really must specify, is
>     whether a community received N times, MUST be considered as
>     received N times or 1 time, because this impacts the meaning,
>     hence the interop. e.g. if the community means prepend one, does
>     sending it N times means prepend N or prepend 1)
>     If so, it seems to never make sense to send the same value
>     multiple times. So it seems clearer to completely forbid it (MUST
>     NOT) rather than leaving the option to re-open the discussion
>     latter or consider how the receiver need to react to "keep the
>     meaning" intended by the originator. Especially since some
>     combination seems to make less sense. e.g. "SHOULD NOT be sent,
>     SHOULD be removed" where we are opening the option to send
>     duplicate, but we don't define how such duplicate will propagate,
>     so the originator has even less reason to try an innovative
>     unspecified behavior.
>
>     Now, if we have "MUST NOT be sent", then I think that this is an
>     error condition if we receive duplicate. And I see 3 options:
>     b) try to stop the error, by correcting it (i.e. "remove
>     duplicate") but that seem to assume that the error is on the
>     sending side, while the error could in fact be on the receiving
>     side. It's bothers me a little that this point had never been
>     discussed by the WG, especially since for the receiver (coder),
>     there is a clear bias in favor of trusting itself (himself). While
>     we had real world example where the error was on the receiving
>     side or at least not on the sending side (e.g. error due to code
>     point collision, e.g. VPN extended community 0x010a, and more
>     recently attributes in draft-ietf-idr-deprecate-30-31-129)
>     c) try to stop the error, with no assumption on the source of the
>     error, by withdrawing the error (Attribute discard or
>     Treat-As-Withdraw). Would be TAW in our case.
>
>     I had suggested "treat-as-withdraw" as a provocation to trigger
>     the discussion, which had never happened. But personally I don't
>     care much on the action, provided that the interpretation is not
>     ambiguous. e.g. MUST be considered as received 1 time.
>
>     Again, I fine with latest version (-08). I'm less fine with the
>     -06 version, especially as the behavior on the receiving side is
>     not strictly defined and may not be interoperable (-06 allows
>     keeping duplicate while not defining its meaning)
>
>     Thanks,
>     --Bruno
>
>      > Thanks,
>      > Jakob.
>      >
>      >
>      > > On Nov 15, 2016, at 6:39 AM, "[email-masked]
>     <mailto:[email-masked]>"
>      > <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      > >
>      > > John, Sue,
>      > >
>      > >> From: Idr [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of John G. Scudder  >
>     Sent: Monday,
>      > >>> On Nov 14, 2016, at 6:10 PM, John G. Scudder
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      > >> Given there's debate regarding the SHOULD/MUST change, I
>     think it's not appropriate
>      > to
>      > >> assume silence gives consent to the change. So, I take that
>     back and expect we will
>      > judge
>      > >> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/idr>
>      > >
>      > >
>      >
>      > > Ce message et ses pieces jointes peuvent contenir des
>     informations confidentielles ou
>      > > pas etre diffuses, exploites ou copies sans autorisation. Si
>     vous avez recu ce message
>      > > a l'expediteur et le detruire ainsi que les pieces jointes.
>     Les messages electroniques
>      > > Orange decline toute responsabilite si ce message a ete
>     altere, deforme ou falsifie.
>      > Merci.
>      > >
>      > > If you have received this email in error, please notify the
>     sender and delete this
>      > > As emails may be altered, Orange is not liable for messages
>     that have been modified,
>      > changed or falsified.
>      > > Thank you.
>      > >
>      > > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>     avez recu ce message par erreur, veuillez le signaler
>     messages electroniques etant susceptibles d'alteration,
>     deforme ou falsifie. Merci.
>
>     privileged information that may be protected by law;
>     and delete this message and its attachments.
>     As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.
>     Thank you.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>
>

-- 
Met vriendelijke groet / Kindest regards,
Martijn Schmidt

i3D.net performance hosting 	
*Martijn Schmidt | Network Architect*
Email: [email-masked] <mailto://[email-masked]> | Tel:
+31 10 8900070

*i3D.net B.V. | Global Backbone AS49544*
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website
<http://www.i3d.net/?utm_source=emailsignature&utm_medium=email&utm_campaign=home>
| Case Studies
<http://www.i3d.net/partners/?utm_source=emailsignature&utm_medium=email&utm_campaign=case-studies>
| LinkedIn <https://www.linkedin.com/company/i3d-net>

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 23:34:43 +0900

> signal such requirement ?

You copy+pasted what i described as an "abomination implementation" here
https://mailarchive.ietf.org/arch/msg/idr/0Uv77wdj2U_kAskiz8LOqGUIFKc

- Job

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 15 Nov 2016 19:09:03 +0100

And what stops you from having a bit smarter clauses where you regex match
on exactly one, two or N occurences of a given community string anywhere in
your received community list following different local PREPEND action ???

Expanded matches for communities have been supported for years.

Thx,
R.

On Nov 15, 2016 11:28 PM, "i3D.net - Martijn Schmidt" <
[email-masked]> wrote:

> Hi Robert,
>
> Route-maps don't work that way in today's router software, every clause is
> evaluated once and then the route-map execution either stops (if no
> continue statement is given) or proceeds to the next clause (if a continue
> statement is given). Either way, the community will only be matched once
> even if it's been tagged twice on the same prefix.
>
> Best regards,
> Martijn
>
>> Taking a step back, I think that what we really must specify, is whether
>> a community received N times, MUST be considered as received N times or 1
>> If so, it seems to never make sense to send the same value multiple
>> times. So it seems clearer to completely forbid it (MUST NOT) rather than
>> leaving the option to re-open the discussion latter or consider how the
>> receiver need to react to "keep the meaning" intended by the originator.
>> Especially since some combination seems to make less sense. e.g. "SHOULD
>> NOT be sent, SHOULD be removed" where we are opening the option to send
>> duplicate, but we don't define how such duplicate will propagate, so the
>> originator has even less reason to try an innovative unspecified behavior.
>>
>>  > >> assume silence gives consent to the change. So, I take that back
>> and expect we will
>>  > judge
>> _____________
>> been modified, changed or falsified.
>> Thank you.
>>
> Idr mailing [email-masked]://www.ietf.org/mailman/listinfo/idr
>
>
> --
> Email: [email-masked] <//[email-masked]> | Tel: +31 10
> 8900070
>

---

From: heasley <[email-masked]>
Date: Tue, 15 Nov 2016 18:26:48 +0000

> Expanded matches for communities have been supported for years.

why would AS3 not just offer communities for 1 - 6 prepends?  at some point,
the number of prepends is pointless and AS1 could cause AS2 to prepend or
prepend itself to achieve the same effect.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 15 Nov 2016 12:44:04 -0800

> execute prepend on the same very prefix P.

Regardless of the rationale on the parts of AS1 and/or AS2, here is the
semantic issue:
A given community is a FLAG. You can use any number of DIFFERENT flags
(community values), but each community value can only be "present" or
"absent".

So, in your example, the presence or absence of the specific community
(AS3->X prepend once), has been defined by AS3. Its presence triggers the
behavior, and its absence does not.
Regardless of who sets the community (adds it to the set), that is the only
available behavior defined by (and for) AS3.
What AS2 does, is in effect, a logical "OR" between the received prefix's
"presence", and the locally asserted "presence".
It passes an unset flag, or passes a set flag, or sets an unset flag, or
sets an already-set flag  (which is a no-op).
There is no "send two copies".

> intended. Why we would drop it ?
You should not drop it, you should silently drop every copy beyond the
first, and then act on it. There is only one community, in the sense of a
specific community value as a flag.

> signal such requirement ?
This boils down to the namespace. The name space is "owned" by AS3, and
what AS3 offers or does not offer, is entirely up to AS3.

If AS2 wants something that AS3 does not offer, the only options that exist
are in "meat space": the operators of AS2 can try to persuade the operators
of AS3 to offer it. Unless and until they do, there is no mechanism for AS2
to "force" AS3 to do what it wants. This is by design.

AS2 might want a pony. AS2 might think it NEEDS a pony. Nothing AS2 does
can make AS3 give AS2 a pony.

(If AS2 is able to achieve the same result with local action, such as doing
prepends itself, the issue is moot and not in scope for communities, and
probably sufficient to solve the problem)
(AS2 might also want to investigate the use of the "origin" attribute,
which can be set differentially to various peers, and influence the path
choice, similar to a "fractional AS prepend".)

Brian

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 15 Nov 2016 21:17:01 +0000

You could also add a community to say 1 prepend and another community to say 2 prepends, to achieve 3 prepends. That won't happen. Some ISPs have text to that effect in their community specifications.

Likewise, we are saying in our draft that duplicates are of no significance. We could add some significance, but we won't. This is consistent with the behavior of 1997 communities, even though RFC 1997 doesn't say it in so many words.

Thanks,
Jakob.

On Nov 16, 2016, at 5:44 AM, Brian Dickson <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Nov 15, 2016 at 6:19 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bruno,

AS3 publishes community with action if I receive this community I will PREPEND my AS# one time towards my peer X.

Now AS1 comes with a need for such prepend on PI prefix P. Then AS2 for perhaps completely different reason also comes up with idea to hint AS3 to execute prepend on the same very prefix P.

Regardless of the rationale on the parts of AS1 and/or AS2, here is the semantic issue:
A given community is a FLAG. You can use any number of DIFFERENT flags (community values), but each community value can only be "present" or "absent".

So, in your example, the presence or absence of the specific community (AS3->X prepend once), has been defined by AS3. Its presence triggers the behavior, and its absence does not.
Regardless of who sets the community (adds it to the set), that is the only available behavior defined by (and for) AS3.
What AS2 does, is in effect, a logical "OR" between the received prefix's "presence", and the locally asserted "presence".
It passes an unset flag, or passes a set flag, or sets an unset flag, or sets an already-set flag  (which is a no-op).
There is no "send two copies".

So AS3 is receiving the two communities which both are valid and truely intended. Why we would drop it ?

You should not drop it, you should silently drop every copy beyond the first, and then act on it. There is only one community, in the sense of a specific community value as a flag.

I admit when the topic came up originally the major concern to me was to prevent stuffing community with N identical sets of values by same AS.

But even this case can be legitimate. Let's consider that said AS2  needs prepend by 2 to some prefixes and AS3 offers *only* community of single PREPEND. Why not adding it twice to such selected prefixes not be a way to signal such requirement ?

This boils down to the namespace. The name space is "owned" by AS3, and what AS3 offers or does not offer, is entirely up to AS3.

If AS2 wants something that AS3 does not offer, the only options that exist are in "meat space": the operators of AS2 can try to persuade the operators of AS3 to offer it. Unless and until they do, there is no mechanism for AS2 to "force" AS3 to do what it wants. This is by design.

AS2 might want a pony. AS2 might think it NEEDS a pony. Nothing AS2 does can make AS3 give AS2 a pony.

(If AS2 is able to achieve the same result with local action, such as doing prepends itself, the issue is moot and not in scope for communities, and probably sufficient to solve the problem)
(AS2 might also want to investigate the use of the "origin" attribute, which can be set differentially to various peers, and influence the path choice, similar to a "fractional AS prepend".)

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 15 Nov 2016 23:17:06 +0100

Hi,

If AS1 or AS2 can prepend themselves there is no issue.

However the issue with AS3 offering 1-6 is that if AS2 end point is to
prepend at AS3 just by 1 AS2 would need to delete community  set by AS1 and
replace it by offered by AS3 prepend by 2.

As to the last point Jakob made that AS3 would not execute +1 prepend and
+2 prepend communities it is interesting how does AS3 knows who set each of
those and which one to not execute.

Thx,
R.

On Nov 16, 2016 3:26 AM, "heasley" <[email-masked]> wrote:

> continue
> needs

---

From: heasley <[email-masked]>
Date: Tue, 15 Nov 2016 22:27:38 +0000

> those and which one to not execute.

it does not know; i think that jakob is just commenting on the manner in which
RPLs normally function.  the communities are checked in an order, and once
seen the checking ceases.  Some RPLs offer ways to check all, but the operator
would have to account for that.

i think this discussion is becoming silly.  can god make a boulder so big that
he himself can not lift it.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Nov 2016 22:56:55 +0000

> he himself can not lift it.

+1

the existing semantics work nicely in practice. There is no compelling
reason to change them.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Nov 2016 00:40:03 +0100

If large is to be like 1997 and if current semantics works why is this
entire debate of special handling duplicates.

Entire section can be removed and what the guy who is inserting and the one
who is acting on be left completely up to them.

Thx,
R.

On Nov 16, 2016 7:57 AM, "Nick Hilliard" <[email-masked]> wrote:

+1

Nick

---

From: Brian Dickson <[email-masked]>
Date: Tue, 15 Nov 2016 15:53:58 -0800

The current IMPLEMENTATIONS handle the issue of duplicates.

The "large" I-D raised the question of whether to memorialize the correct
behavior.

IMHO, the absence of it in 1997, is an issue to raise in a future 1997-bis.
(I think it's a bit too big to do as an errata.)

The current language in large needs to be kept.

IMHO.

Brian

On Tue, Nov 15, 2016 at 3:40 PM, Robert Raszuk <[email-masked]> wrote:

> Entire section can be removed and what the guy who is inserting and the
> one who is acting on be left completely up to them.
>
> Thx,
> R.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Nov 2016 19:12:46 -0500

> (community values), but each community value can only be "present" or

For what it's worth, I always explain communities as being a "set", in a
mathematical sense.

In that notion, A union A yields the set containing A, etc.

Match operations are typically either intersect or proper subset operations.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 16 Nov 2016 13:01:03 +0900

Hi Everyone,

After Bruno's comments regarding RFC 7606 style error handling being invoked to react to duplicate community values, a few people have expressed (on and off list) concern that even though that is not intended, the -08 text as written could possibly be misinterpreted by a zealous implementor. To resolve this, I propose adding the following, or similar, to the Error Handling section:

o A BGP Large Communities attribute SHALL NOT be considered malformed due 
  solely to presence of duplicate community values. Such duplicates MUST be handled 
  by removing them as specified in Section 2.

IMO this clarifies the intent of the document and doesn't represent a normative change. Hopefully it will resolve the concerns of those who were concerned about and opposed to 7606-style handling for duplicates.

The authors have indicated they'll incorporate the text in an -09 (assuming of course that the consensus of the WGLC doesn't go against the change).

Regards,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Nov 2016 23:14:26 -0500

John: 
<individual contributors hat on>
+1 on the new text. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Tuesday, November 15, 2016 11:01 PM
To: idr wg
Subject: Re: [Idr] One week extension to WGLC for
draft-ietf-idr-large-community

Hi Everyone,

After Bruno's comments regarding RFC 7606 style error handling being invoked
to react to duplicate community values, a few people have expressed (on and
off list) concern that even though that is not intended, the -08 text as
written could possibly be misinterpreted by a zealous implementor. To
resolve this, I propose adding the following, or similar, to the Error
Handling section:

o A BGP Large Communities attribute SHALL NOT be considered malformed due 
  solely to presence of duplicate community values. Such duplicates MUST be
handled 
  by removing them as specified in Section 2.

IMO this clarifies the intent of the document and doesn't represent a
normative change. Hopefully it will resolve the concerns of those who were
concerned about and opposed to 7606-style handling for duplicates.

The authors have indicated they'll incorporate the text in an -09 (assuming
of course that the consensus of the WGLC doesn't go against the change).

Regards,

--John

---

From: Geoff Huston <[email-masked]>
Date: Wed, 16 Nov 2016 15:40:48 +1100

> On 16 Nov. 2016, at 3:01 pm, John G. Scudder <[email-masked]> wrote:
> 
> Hi Everyone,
> 

As someone who has commented on previous wordings of this intent, I’d like to say that I am very happy with this wording.

Geoff

---

From: "Russ White" <[email-masked]>
Date: Wed, 16 Nov 2016 00:09:53 -0500

> > o A BGP Large Communities attribute SHALL NOT be considered malformed
> > due  solely to presence of duplicate community values. Such duplicates
> > MUST be handled  by removing them as specified in Section 2.

This is a useful addition... And it seems to resolve the problem at hand well.

:-)

Russ

---

From: heasley <[email-masked]>
Date: Wed, 16 Nov 2016 08:16:23 +0000

> IMO this clarifies the intent of the document and doesn't represent a normative change. Hopefully it will resolve the concerns of those who were concerned about and opposed to 7606-style handling f…

I do not understand why this is necessary.  -08 already indicates that
duplicates should be silently ignored.  And, nothing in section 6 implies
that it would be considered an error.

I dont object, but i do think this is redundant and unnecessary.

---

From: Peter Hessler <[email-masked]>
Date: Wed, 16 Nov 2016 10:31:50 +0100

On 2016 Nov 16 (Wed) at 13:01:03 +0900 (+0900), John G. Scudder wrote:
:Hi Everyone,
:
:After Bruno's comments regarding RFC 7606 style error handling being invoked to react to duplicate community values, a few people have expressed (on and off list) concern that even though that is not intended, the -08 text as written could possibly be misinterpreted by a zealous implementor. To resolve this, I propose adding the following, or similar, to the Error Handling section:
:
:o A BGP Large Communities attribute SHALL NOT be considered malformed due 
:  solely to presence of duplicate community values. Such duplicates MUST be handled 
:  by removing them as specified in Section 2.
:

+100

This exactly addresses my original objection.

:IMO this clarifies the intent of the document and doesn't represent a normative change. Hopefully it will resolve the concerns of those who were concerned about and opposed to 7606-style handling for duplicates.
:
:The authors have indicated they'll incorporate the text in an -09 (assuming of course that the consensus of the WGLC doesn't go against the change).
:
:Regards,
:
:--John

-- 
Do not believe in miracles -- rely on them.

---

From: Gert Doering <[email-masked]>
Date: Wed, 16 Nov 2016 10:41:27 +0100

Hi,

+1

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Nov 2016 16:05:57 +0100

Hi,

> Op 16 nov. 2016, om 05:40 heeft Geoff Huston <[email-masked]> het volgende geschreven:
> 

Same for me: +1
Sander

---

From: t.petch <[email-masked]>
Date: Fri, 18 Nov 2016 10:58:23 +0000

John

I am happy with the proposed text but ...

An issue that came up earlier and that I did not see resolved was what
constitutes a duplicate.  This is binary so we don't have the issues
that
character comparisons do but is it the same bit pattern from start to
finish, the same semantics or something between the two?  A case I have
in mind is when the same semantics appear in RFC1997 format and also
in LC format; is that a duplicate?.

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "idr wg" <[email-masked]>
Sent: Wednesday, November 16, 2016 4:01 AM

> Hi Everyone,
>
> After Bruno's comments regarding RFC 7606 style error handling being
invoked to react to duplicate community values, a few people have
expressed (on and off list) concern that even though that is not
intended, the -08 text as written could possibly be misinterpreted by a
zealous implementor. To resolve this, I propose adding the following, or
> o A BGP Large Communities attribute SHALL NOT be considered malformed
due
> IMO this clarifies the intent of the document and doesn't represent a
normative change. Hopefully it will resolve the concerns of those who
were concerned about and opposed to 7606-style handling for duplicates.
>
> The authors have indicated they'll incorporate the text in an -09
(assuming of course that the consensus of the WGLC doesn't go against
the change).

---

From: "Dickinson, Ian" <[email-masked]>
Date: Fri, 18 Nov 2016 11:47:01 +0000

I would say that large and 1997 communities are different things and cannot be duplicates at the protocol level.
Operators can configure policy that would choose which took precedence (regardless of semantic equivalence or otherwise).

Ian

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of t.petch
Sent: 18 November 2016 10:58
To: John G. Scudder <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community

John

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "idr wg" <[email-masked]>
Sent: Wednesday, November 16, 2016 4:01 AM

due

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: "Dickinson, Ian" <[email-masked]>
Date: Fri, 18 Nov 2016 11:58:04 +0000

Apologies for a 2nd post - I hit send too early. The intended version is below:

Only bit pattern duplication makes sense here, as protocol cannot understand operator defined semantics.
I would say that large and 1997 communities are different things and cannot be duplicates at the protocol level.
Both would be required to be able to perform a viable transition from 1997 to large..
Operators can configure policy that would choose which took precedence (regardless of semantic equivalence or otherwise).

Ian

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Dickinson, Ian
Sent: 18 November 2016 11:47
To: t.petch <[email-masked]>; John G. Scudder <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community

Ian

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of t.petch
Sent: 18 November 2016 10:58
To: John G. Scudder <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community

John

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "idr wg" <[email-masked]>
Sent: Wednesday, November 16, 2016 4:01 AM

due

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 18 Nov 2016 19:37:09 +0000

What he said

Thanks,
Jakob.

> On Nov 18, 2016, at 3:58 AM, Dickinson, Ian <[email-masked]> wrote:
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 18 Nov 2016 19:40:46 +0000

I don't believe that any text is required to resolve this.

Thanks,
Jakob.

> On Nov 18, 2016, at 11:37 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> What he said
> 
> Thanks,
> Jakob.
>

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 19 Nov 2016 11:12:56 +0000

t.petch wrote:
> An issue that came up earlier and that I did not see resolved was
> what constitutes a duplicate.  This is binary so we don't have the
> issues that character comparisons do but is it the same bit pattern
> from start to finish, the same semantics or something between the
> two?  A case I have in mind is when the same semantics appear in
> RFC1997 format and also in LC format; is that a duplicate?.

rfc1997 and LC being different namespaces, no.

Nick

---

From: t.petch <[email-masked]>
Date: Sun, 20 Nov 2016 10:17:20 +0000

----- Original Message -----
From: "Nick Hilliard" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>; "idr wg" <[email-masked]>
Sent: Saturday, November 19, 2016 11:12 AM
> rfc1997 and LC being different namespaces, no.

So you have someone been happily using RFC1997 for years with success
when one of their pesky peers goes and gets a 32-bit ASN and suddenly
they cannot use RFC1997 any more and have to start using LC, to do
exactly the same thing as they have been doing for ages.

We are now saying 'ah no, this is two separate unrelated bits of
technology that cannot be compared and you must treat as different'.
Someone with a 32-bit ASN is in a different universe to someone with a
16-bit ASN.

Mmmm not very friendly.

Tom Petch

---

From: Job Snijders <[email-masked]>
Date: Sun, 20 Nov 2016 13:59:39 +0100

> Someone with a 32-bit ASN is in a different universe to someone with a

I find it disingenuous to refer to 32-bit ASNs as 'pesky peers', you
very well know that the 16-bit pool has been depleted: IANA no longer
has 16-bit ASNs. Most RIRs are almost out or sitting on small reserves
of 16-bit ASns. Soon there simply won't be any choice but to use 32-bit
ASNs. 

When RFC 4893 was introduced, it was obvious that there would be gaps in
terms of feature parity, such as BGP Communities and GLOP space. Things
would not be the same. Within RFC 4893 itself, there is transition
measure involving the 23456 ASN. This transition measure did not allow
for actual policy transition, as the information it communicated added
up to what was essentially "here be dragons". Until operators upgraded
to firmware with RFC4893 support, crafting uniform policy for 16-bit and
32-bit AS paths was not feasible.

In this proposal, we've chosen not to introduce such a measure, as
generic approach to mapping 96 bits into 32 bits simply isn't
reasonable, and can't be done meaningfully.

Just as the case was with RFC 4893, RFC 1997 and Large Communities will
coexist side by side for some time. Vendors can implement mapping
primitives at the router level which would allow for mapping and
transformation. But these are local considerations.

I am disappointed that you _again_ bring up the topic of mapping between
RFC 1997 and Large Communities, which has already been discussed and
concluded as out-of-scope for this draft.

The most unfriendly thing we can do now is leave our 32-bit peers out in
the cold, without functional community space they can use for
implementing policy. Please just get out of the way.

Regards,

Job

---

From: Gert Doering <[email-masked]>
Date: Sun, 20 Nov 2016 14:34:07 +0100

Hi,

> Someone with a 32-bit ASN is in a different universe to someone with a

This is not what Nick was saying, so don't try to make it.

Nick was saying that to argue that LC de-duplication should not take 
1997 communities into account, because that's a different namespace.

But in the end, what you say is what the IETF *made* it to be, due to
the insane delay in providing a 32bit equivalent to 1997 communities - 
folks with an older implementation living in 16 bit space will now
have issues setting community values to effect 32bit AS <-> 32bit AS
relations (like, exchange point route servers) because there just is
no way to express this with 1997 communities.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 20 Nov 2016 15:35:22 +0100

> Someone with a 32-bit ASN is in a different universe to someone with a

Given that this was brought up before, commented on in depth, then
closed off as not being relevant to the draft, and where this closure
was assessed as having consensus, I'm not sure why it's appropriate to
bring the topic up again.

If you have an issue with the consensus call that was previously made,
this is something that you should take up with the chairs.

Nick