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

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, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:
> 
> John, Sue,
> 
>> From: Idr [mailto:idr-bounces@ietf.org] 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 <jgs@juniper.net> 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
>> Idr@ietf.org
>> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr