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

[Robert Raszuk <[e-mail]>]

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" <
[e-mail]> 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
>
> On 11/15/2016 03:19 PM, Robert Raszuk wrote:
>
> 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
>>
>
>
> _______________________________________________
> Idr mailing [e-mail]://www.ietf.org/mailman/listinfo/idr
>
>
> --
> Met vriendelijke groet / Kindest regards,
> Martijn Schmidt
>
>
> [image: i3D.net performance hosting]
> *Martijn Schmidt | Network Architect*
> Email: [e-mail] <//[e-mail]> | 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>
>
>