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

["Alvaro Retana (aretana)" <[e-mail]>]

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

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.