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

["i3D.net - Martijn Schmidt" <[e-mail]>]

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

-- 
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


i3D.net performance hosting 	
*Martijn Schmidt | Network Architect*
Email: [e-mail] <mailto://[e-mail]> | Tel:
[phone]

*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>