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

[Robert Raszuk <[e-mail]>]

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, <[e-mail]> 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:[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.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>