Subject: [Idr] draft-ietf-idr-custom-decision-00

From: <[email-masked]>
Date: Wed, 7 Dec 2011 16:38:36 +0100

Alvaro, Russ, all

Draft says:

"  If the non-transitive version of a Cost Community is received across
   an Autonomous System boundary, then the receiver SHOULD strip it off
   the BGP update, and ignore it when running the selection process."

1) IMHO, for consistency, the handling of non-transitive community,
should be defined in a single document (rfc4360) rather than in each
document defining a new extended community.

2) There has been some discussion regarding the handling of non
transitive community over an eBGP session:
http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00
presented in IETF 76. The feeling I got at the time, was that the
intention of RFC 4360 was to prohibit the propagation to an eBGP session
of a non-transitive community being in the loc_RIB. But that it was
possible to set a non-transitive attribute in the outbound policy of an
eBGP session. --> hence the eBGP peer should not remove the received
non-transitive community

(for reference RFC 4360 says "If a route has a non-transitivity extended
community, then before advertising the route across the Autonomous
System boundary the community SHOULD be removed from the route.")

Hence, would you consider removing the above sentence from the draft?

Thanks,
Regards,
Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 07 Dec 2011 23:12:13 +0100

Hi Bruno,

I think you are bringing a very important topic - however I think I am 
not in line with your suggestion.

As we have discussed in Prague there is general need to handle 
customizations for best path selection. Such customization may be 
required to span domains. So rather then remove anything how the 
non-transitive community should be handled I would rather see proposal 
how to make safely cost community to be transitive across domains.

Once we do that proposals like AIGP would be automatically addressed by 
operator's configuration without any need for new drafts or RFCs.

Best regards,
R.

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: <[email-masked]>
Date: Thu, 8 Dec 2011 09:46:49 +0100

Hi Robert, all

>From: Robert Raszuk [mailto:[email-masked]] Sent: Wednesday,
December 07, 2011 11:12 PM
>customizations for best path selection.

Ok.

> Such customization may be required to span domains. 

Agreed.

>So rather then remove anything how the

- I'm not proposing to remove anything on how non-transitive communities
are to be handled. I'm proposing the behavior be agreed on and specified
in a single document: RFC 4360(bis)
- Note that idr-customer-decision proposes to reserve 2 opaque extended
community types: one transitive and one non transitive. So the
transitive one is already a way to have the cost community usable across
domains.
- Finally, my proposition goes in the direction you ask (make the cost
community be usable across domain) as it remove a restriction for using
it on eBGP sessions. 

That's completely orthogonal to my comment.
My point is that extended communities are already specified in RFC 4360.
So either the extended community is the right tool for custom-decision
or it's not. That is up to authors of draft-ietf-idr-custom-decision.
IMHO, what is not is redefining how (non-transitive) extended
communities are to be handled. That is of course a personal opinion
only, it's up to the WG/chairs to decide.

Best regards,
Bruno