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

[<[e-mail]>]

Hi Alvaro,

Thanks for the discussion and the proposed change.
I indeed think that separating the "high order bit" in its own field will help clarifying the text. I'll wait for next revision since I expect a few changes in the text.
Please see 1 point inline [Bruno]

From: Alvaro Retana (aretana) [mailto:[e-mail]]
Sent: Monday, November 16, 2015 8:03 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)

On 11/16/15, 11:24 AM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:

Bruno:

Hi!

Looks good to me, except one point regarding the security consideration. Then I also have some further comments.

--
>>§6.  Security Considerations

[...]
>> a) by default, this mechanism is activated.
>> b) non compliant implementation will accept and pass transitive Opaque community (0x03)

>> a+ b): anyone in the Internet can influence the routing in my AS; which is not acceptable.

> Yes, you're right.  We added considerations to turn it off by default.

I've only seen "MUST not propagate by default" which is not something this document can enforce on non-compliant ASBR. Hence some non compliant ASBR will accept this Cost  Community from unstrusted source/AS and propagate it within the AS.
IMO, we need that by defaut, the cost community MUST NOT affect the BGP decision process.

I think that this case is addressed in the text below (mod transitive + non-transitive).
[Bruno] I don't think so.
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.

Thanks
-- Bruno
You're right that a non-compliant implementation can do what is not specified (accept, propagate, use).  The same obviously applies to any other normative language we can add..




"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."


Transitive and non-transitive (MUST be stripped off) (As RFC 4360 does not specify to remove non-transitive community received over eBGP.)

The last sentence in Section 4 (Operation) reads:

   If the non-transitive version of a Cost Community is received across
   an Autonomous System boundary, then the receiver MUST strip it off
   the BGP update, and ignore it during the Decision Process.

I think we were thinking about the inter-AS case when we wrote the Security Considerations..so we left the non-transitive part out.  We can add it in the next revision to make sure it is clear.


---

OLD: If the high-order bit is set, the Cost in the Cost Community
         may replace the value of a path attribute at a specific step in
         the Decision Process, but not the attribute itself.
NEW: If the high-order bit is set, the Cost in the Cost Community
         replace the value of a path attribute at a specific step in
         the Decision Process, but not the attribute itself.

Will fix in the next revision.



---

"   Multiple Cost Communities may indicate the same POI.  All the Cost

   Communities for a specific POI MUST be considered starting with the

   one(s) with the lowest Community-ID. "

By "lowest Community-ID" it's not clear to me whether the high order bit (indicating _after_ or _instead_ the related BGP attribute) is taken into account or not (i.e. should be masked before the comparison).
IMHO I would favor not taking this bit into account as, a priori, I don't see a reason to give preference to POI _after_.  In which case, as a related comment, IMHO the first figure of section 3, should indicate this high order bit as a separate field.
Regardless of your choice, IMO the expected behavior should be explicitly stated.

We'll change the drawing to indicate the bit separately and clarify what the ID is - in the next revision.


 "All the Cost Communities for a specific POI MUST be considered"

I'm not sure I would consider comparable "POI X & High-Order bit 1" with "POI X & High-Order bit 0". To me, looks like nearly equally different than POI X and POI X+1.

Oh, that doesn't mean that they are compared against each other.  As you point out, the "effective POI" with the high-order bit set is different than without it.

Along with your other comment about the ID and the high-order bit, we'll also clarify the meaning of POI.

By separating the high-order bit into its own field the meaning of the ID is cleared.  We'll call it the "Replace Bit" (R-bit).   I'm thinking of adding a new term called the Point of Application (POA), which is the place in the Decision Process where the Cost Community is evaluated.  If the R-bit is not set, then the POA is after the step in the Decision Process indicated by the POI; if the R-bit is set, then the POA is at the POI.  I'll then s/POI/POA in Operation, etc. which should result in the clarified behavior.   Thoughts?

 --

"   Routes that do not contain the Cost Community (for a valid,

   particular POI),or a Community-ID present in a route from another

   peer, MUST be considered to have the default Cost"

"(for a valid, particular POI" + and high-order bit of the community-ID.

Yes..  As above.

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.