Re: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Bruno,

Comments inline marked with [Sriram].

>[Bruno] - RFC7606 provides a guidance https://datatracker.ietf.org/doc/html/rfc7606#section-8<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7606%23section-8&data=04%7C01%7Ckotikalapudi.sriram%40nist.gov%7Cb7a059d3cee145ca531c08d9f0a3c35f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637805408436586543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fsbz%2B8gTR8c0r94m4SoaamR4O%2BmHiMYH5tY9uRCXTHk%3D&reserved=0> . It's only half a page so anyone interested could read. I don't think it can be summarized as per you above sentence.

[Sriram] Section 8 of RFC 7606 that you cite, says:

   A document that specifies a new BGP attribute MUST provide specifics
   regarding what constitutes an error for that attribute and how that
   error is to be handled.  Allowable error-handling approaches are
   detailed in Section 2.

[Sriram] From the list of error-handling approaches detailed in Section 2, only treat-as-withdraw and attribute discard are relevant for us. Since the RFC says, "Allowable error-handling approaches are detailed in Section 2",  it does not allow for applying none of the approaches as an option.

>[Bruno] In particular there is not such "SHALL be handled using the approach of "treat-as-withdraw".

[Sriram] Regarding attribute discard, RFC 7606 says: "This approach MUST NOT be used except in the case of an attribute that has no effect on route selection or installation." This implies: This approach MUST NOT be used in the case of an attribute that has an effect on route selection or installation. Do you agree? The route does propagate from iBGP (ingress) to eBGP (in the ASBR), where the attribute plays a role in route selection for propagation.

>[Bruno] It also specifically calls for attention to optional transitive attributes (such as OTC) for which "the damage inflicted may be multiplied  manyfold >

[Sriram] The "damage inflicted may be multiplied manyfold" is about session reset. That is why the RFC urges the use of treas-as-withdraw or attribute discard instead.

>[Bruno] Without double checking, I don't recall that OTC is acted upon within IBGP. So in this case it does not affect routing selection. Let's just specify to not even look at it (it's optional) and problem is solved.

[Sriram] iBGP and eBGP within an ASBR are not isolated operations. Please see my comment above. Not to look at OTC is not an option. A compliant router checks syntax errors in iBGP (just as in eBGP) based on its expectations of the OTC Attribute. If the length value does not match, the Attribute is malformed.

[Sriram] If the OTC attribute is malformed for any reason, we cannot be sure that even the Attribute type value is correct (or as intended). Then must it be propagated from iBGP to eBGP (in the ASBR) and then to eBGP neighbors?

Thanks.

Sriram