Re: [Idr] Review of draft-ietf-large-community-06

[Mach Chen <[e-mail]>]

Hi Jakob,

Thanks for your prompt response!

Please see my reply inline...

> -----Original Message-----
> From: Jakob Heitz (jheitz) [mailto:[e-mail]]
> Sent: Wednesday, November 09, 2016 1:03 AM
> To: Job Snijders
> Cc: Mach Chen; IETF IDR WG
> Subject: Re: [Idr] Review of draft-ietf-large-community-06
> 
> 
> > On Nov 8, 2016, at 3:26 AM, Job Snijders <[e-mail]> wrote:
> >
> >> On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
> >>
> >> Section 2, the last sentence:
> >> "A receiving speaker SHOULD silently remove duplicate Large BGP
> >> Communities from a BGP UPDATE message."
> >>
> >> IMHO, whether remove the duplicate communities from a BGP UPDATE
> >> message is not significant, since the life of the message is over
> >> once the message processed.
> 
> That's not what happens. After a route is originated, it passes through many
> BGP speakers and typically ends up in most routing tables on earth. Each
> speaker that sees the route may or may not interpret all the communities and
> may or may not propagate the communities. However, any BGP speaker that
> receives a community attribute SHOULD remove duplicate communities before
> propagating the attribute. Also any BGP speaker is free to propagate
> communities in a different order than it received them.

Yes, this is true and I agree.

> 
> What actually happens in two code bases that I have worked on: A receiving
> speaker will sort the received communities and remove duplicates. This

This also aligns with my worked codes. But the point is that it does not remove the duplicate values from the received message. The duplicate values should be ignored and dropped.
Normally, a BGP message will be terminated at the receiving speaker, when it needs to send messages to other speakers, the messages are actually new generated ones. Of cause, this is more about implementation details.

I am fine with the new text Job proposed in the upcoming version 07.

Thanks,
Mach

> happens even if the receiving speaker simply propagates the communities
> without interpretation. This applies to legacy communities and the same
> behavior is carried on in my large community code.
> 
> 
> >> The key point is that the receiving speaker should ignore the
> >> duplicate Large BGP Communities.
> >>
> >> How about:
> >>
> >> "A receiving speaker SHOULD silently ignore the duplicate Large BGP
> >>   Communities within a Large BGP Communities attribute. "
> >
> > After the latest round of review from Geoff Huston and Jakob Heitz the
> > following text was produced.
> >
> > The below text is queued to be in -07 of the draft, but -07 can't be
> > posted yet as we are in the 'cutoff' period before the IETF meeting in
> > Seoul.
> >
> > """
> >    Duplicate BGP Large Community values SHOULD NOT be transmitted. A
> >    receiving speaker SHOULD silently remove duplicate BGP Large
> >    Community values from a BGP Large Community attribute.
> > """
> >
> > I think the above text aligns with your suggestion, right?
> 
> 
> Thanks,
> Jakob.