Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 3 Feb 2017 20:16:38 +0000

Bruno:

Hi!

We just refreshed the draft…and (I think) clarified your point below in the Security Considerations:

Section 6., paragraph 2:
OLD:

    To minimize the potential of creating routing loops (Section 5) or
    otherwise affecting the Decision Process in unintended ways, the
    propagation of Cost Communities MUST be disabled by default and MUST
    be explicitly enabled by the network administrator.  Furthermore, all
    transitive Cost Communities received across an Autonomous System
    boundary without explicit configuration MUST be stripped off the BGP
    update, and ignored during the Decision Process.

NEW:

    To minimize the potential of creating routing loops (Section 5) or
    otherwise affecting the Decision Process in unintended ways, the
    propagation of Cost Communities MUST be disabled by default and MUST
    be explicitly enabled by the network administrator.  Furthermore, all
    Cost Communities received across an Autonomous System boundary
    without explicitly being enabled MUST be stripped off the BGP update,
    and ignored during the Decision Process.

That is probably the main part, but there are other changes resulting from your comments.  Please take a look at the complete diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-custom-decision-07&url2=draft-ietf-idr-custom-decision-08

Thanks!

Alvaro.

On 11/17/15, 3:35 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

My concern is for an AS not using this cost community:
a) compliant routers will, by default, modify route preference based on the community
b) non compliant routers will, by default, accept this community over eBGP sessions.

a+b: we have an issue as untrusted AS may influence my routing policy or create loops.

We agree that we can’t do anything about “b”.
So I am asking to address “a” by having compliant routers to _not_ change route preference by default. i.e. MUST be explicitly configured to change their route preference based on this community.

---

From: <[email-masked]>
Date: Mon, 6 Feb 2017 15:06:57 +0000

Hi Alvaro,

Thanks for your answer and for the updated draft.

I can live with the current text. Yet, stricto sensus:
- the second sentence only applies to communities received over EBGP, which does not address the case where this ASBR do not support Cost  Communities
- the first sentence only talks about “propagation”, not “use during the Decision Process”.

On my side, I’d propose
OLD: the propagation of Cost Communities MUST be disabled by default
NEW: the use of Cost Communities MUST be disabled by default

Note that I removed “propagation” as, if the goal is to minimize the routing loops, removing Cost Community during iBGP propagation is debatable, as some upstream (related to BGP message propagation) BGP speaker may have already used the cost community; hence removing it may also create loops. However, feel free to add it back as in both cases, we really can’t fix this issue of inconsistent configuration.

FYI a typo   :s/ its oen field/ its own field

Thanks
--Bruno

From: Alvaro Retana (aretana) [mailto:[email-masked]]
Sent: Friday, February 03, 2017 9:17 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]; Susan Hares
Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

Bruno:

Hi!

Section 6., paragraph 2:
OLD:

NEW:

Thanks!

Alvaro.

_________________________________________________________________________________________________________________________

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.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 6 Feb 2017 16:20:18 +0100

Hi Bruno,

On my side, I’d propose
> NEW: the use of Cost Communities MUST be disabled by default

​Do you really think it is safe to propagate ​information which can
completely overwrite Best Path without applying it locally ?

If we are really to change this text how about this:

NEW: The use of Cost Communities MUST be disabled by default. The
propagation may occur by default only on those BGP speakers which do not
set next hop self.

​Cheers,
R.
​

---

From: <[email-masked]>
Date: Mon, 6 Feb 2017 15:51:09 +0000

Hi Robert,

Please see inline [Bruno]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, February 06, 2017 4:20 PM
To: DECRAENE Bruno IMT/OLN
Cc: Alvaro Retana (aretana); [email-masked]; Susan Hares
Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

Hi Bruno,

On my side, I’d propose

​Do you really think it is safe to propagate ​information which can completely overwrite Best Path without applying it locally ?

[Bruno]
1) IIRC, this is exactly what this document does, for all BGP speakers which do not support the cost-community.
2) I’ve said that both choices can lead to forwarding loops. Where do you see that I said it was safe?

NEW: The use of Cost Communities MUST be disabled by default. The propagation may occur by default only on those BGP speakers which do not set next hop self.
[Bruno] I’m fine with the first sentence.
The second sentence introduces a behavior which is per route (rather than per node currently). I don’t really see a strong enough reason for this additional complexity. Especially given that all non-compliant router will propagate it in all cases.

Cheers,
Bruno

​Cheers,
R.
​