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

[<[e-mail]>]

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:[e-mail]]
Sent: Friday, February 03, 2017 9:17 PM
To: DECRAENE Bruno IMT/OLN
Cc: [e-mail]; Susan Hares
Subject: Re: [Idr] 2 week WG LC for draft-ietf-custom-decision (4/20 to 5/4/2015)

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, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> 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.


_________________________________________________________________________________________________________________________

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.