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

[<[e-mail]>]

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:[e-mail]]  > 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.
 > 
 > Therefore, I support SHOULD.

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
 
 > Thanks,
 > Jakob.
 > 
 > 
 > > On Nov 15, 2016, at 6:39 AM, "[e-mail]"
 > <[e-mail]> wrote:
 > >
 > > John, Sue,
 > >
 > >> From: Idr [mailto:[e-mail]] On Behalf Of John G. Scudder  > Sent: Monday,
 > November 14, 2016 7:50 PM
 > >>
 > >> In my role as co-chair:
 > >>
 > >>> On Nov 14, 2016, at 6:10 PM, John G. Scudder <[e-mail]> 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.
 > >
 > > 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
 > >> [e-mail]
 > >> 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.
 > >
 > > _______________________________________________
 > > Idr mailing list
 > > [e-mail]
 > > 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.