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

From: <[email-masked]>
Date: Wed, 16 Feb 2022 14:18:58 +0000

Hi Sriram,

Please see inline [Bruno2]

Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[email-masked]>
Sent: Tuesday, February 15, 2022 11:52 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; Alexander Azimov <[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
Subject: RE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

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.

[Bruno2] First step that RFC7606 does is to define (i.e. choose) what constitute an error. We could define that length is not checked for IBGP because we don't care about the content (or even the attribute). Alternatively, I'm also fine with attribute discard if we consider that the attribute is in error and hence could not be trusted.

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

[Bruno2] 1) For IBGP, OTC attribute has no effect on route selection and installation. 2) Since you seem to be calling for "treat-as-withdraw", I would argue that "treat-as-withdraw" has also an effect on route selection or installation, and a bigger one. So it's not really safer in term of side effect.

>[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.
[Bruno2] It's discussed in the context as session reset, but the cause is the optional transitive attribute. Cf following text which only refers to the type of attribute and not the action taken
   although the problematic attributes may have
   originated with a single update transmitted by a single BGP speaker,
   by the time they encounter a router that checks them they may have
   been replicated many times and thus may cause the reset of many
   peering sessions.  Thus, the damage inflicted may be multiplied
   manyfold.

>[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.
[Bruno2] If this were true, we could not define the OTC as an optional transitive attribute, because essentially some routers will not look at OTC. Pick your 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).
[Bruno2] 1) That's not the path chosen by RFC 7606 in case of a length error. 2) I would find debatable to assume an error on a field (type) when you don't see an error on this field. TLV construct provides hierarchy: I agree that what is inside the TLV (i.e. after/below the error) can't be trusted; but for what is before the error, there is little to no reason to assume an error (and if we do, we could imagine anything and in particular an attribute for which the error handling is "session reset".)

[Sriram] Then must it be propagated from iBGP to eBGP (in the ASBR) and then to eBGP neighbors?
[Bruno2] Current text proposes to _not_ propagate to eBGP neighbors except for Customer. If length is wrong, I would be fine to also not propagate to Customerif you find this better.

Thanks for the discussion
--Bruno

Thanks.

Sriram

_________________________________________________________________________________________________________________________

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: Alexander Azimov <[email-masked]>
Date: Wed, 16 Feb 2022 19:24:05 +0300

Bruno,

Please see the quote from 7.8 of RFC7606 which I see as good example:

   The error handling of [RFC1997
<https://datatracker.ietf.org/doc/html/rfc1997>] is revised as
follows:

   o  The Community attribute SHALL be considered malformed if its
      length is not a non-zero multiple of 4.

   o  An UPDATE message with a malformed Community attribute SHALL be
      handled using the approach of "treat-as-withdraw".

As you can see, there is no difference between processing communities
with malformed length whether they are received thorugh eBGP or iBGP.

And in the context of OTC inside AS one can say that OTC use case and
community use case that are marking routes to prevent leaking is very much
the same, do you agree?

And btw, getting back to your original example, how your proposal will help
to prevent loops if for some reason the internal sessions are configured as
eBGP with private ASNs?

Your last suggestion that restricts route advertisement in all directions
including Customers may improve the situation but in the partial deploy
scenario still may lead to hard to debug issues when routes with malformed
attribute will travel beyond single administrative domain.

ср, 16 февр. 2022 г. в 17:18, <[email-masked]>:

> *From:* Sriram, Kotikalapudi (Fed) <[email-masked]>
> *Sent:* Tuesday, February 15, 2022 11:52 PM
> *To:* DECRAENE Bruno INNOV/NET <[email-masked]>; Alexander
> Azimov <[email-masked]>; Jeffrey Haas <[email-masked]>
> *Cc:* [email-masked]; Alvaro Retana (aretana) <[email-masked]>;
> [email-masked]; Susan Hares <[email-masked]>
> *Subject:* RE: [Idr] FW: New Version Notification for
> draft-ietf-idr-bgp-open-policy-22.txt
>
>
>
> Hi Bruno,
>
>
>
> >[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] 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.
>
>
>
> [Bruno2] First step that RFC7606 does is to define (i.e. choose) what
> constitute an error. We could define that length is not checked for IBGP
> because we don’t care about the content (or even the attribute).
> Alternatively, I’m also fine with attribute discard if we consider that the
> attribute is in error and hence could not be trusted.
>
>
>
> >[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.
>
>
>
> [Bruno2] 1) For IBGP, OTC attribute has no effect on route selection and
> installation. 2) Since you seem to be calling for “treat-as-withdraw”, I
> would argue that “treat-as-withdraw” has also an effect on route selection
> or installation, and a bigger one. So it’s not really safer in term of side
> effect.
>
>
>
> >[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.
>
> [Bruno2] It’s discussed in the context as session reset, but the cause is
> the optional transitive attribute. Cf following text which only refers to
> the type of attribute and not the action taken
>
> >[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.
>
>
>
> [Bruno2] If this were true, we could not define the OTC as an optional
> transitive attribute, because essentially some routers will not look at
> OTC. Pick your 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).
>
> [Bruno2] 1) That’s not the path chosen by RFC 7606 in case of a length
> error. 2) I would find debatable to assume an error on a field (type) when
> you don’t see an error on this field. TLV construct provides hierarchy: I
> agree that what is inside the TLV (i.e. after/below the error) can’t be
> trusted; but for what is before the error, there is little to no reason to
> assume an error (and if we do, we could imagine anything and in particular
> an attribute for which the error handling is “session reset”.)
>
>
>
> [Bruno2] Current text proposes to _*not*_ propagate to eBGP neighbors
> except for Customer. If length is wrong, I would be fine to also not
> propagate to Customerif you find this better.
>
>
>

-- 
Best regards,
Alexander Azimov

---

From: <[email-masked]>
Date: Wed, 16 Feb 2022 16:44:21 +0000

Alexander,

Please see inline [Bruno]

Orange Restricted
From: Alexander Azimov <[email-masked]>
Sent: Wednesday, February 16, 2022 5:24 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: Sriram, Kotikalapudi (Fed) <[email-masked]>; [email-masked]; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>; Jeffrey Haas <[email-masked]>
Subject: Re: ttRE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Bruno,

   The error handling of [RFC1997<https://datatracker.ietf.org/doc/html/rfc1997>] is revised as follows:

As you can see, there is no difference between processing communities with malformed length whether they are received thorugh eBGP or iBGP.

[Bruno] Please see https://datatracker.ietf.org/doc/html/rfc7606#section-7.10 where there is a difference between eBGP and iBGP, both in term of error condition and action taken:

The error handling of [RFC4456<https://datatracker.ietf.org/doc/html/rfc4456>] is revised as follows:

   o  if the CLUSTER_LIST attribute is received from an external
      neighbor, it SHALL be discarded using the approach of "attribute
      discard"; or

   o  if received from an internal neighbor, it SHALL be considered
      malformed if its length is not a non-zero multiple of 4.  If
      malformed, the UPDATE message SHALL be handled using the approach
      of "treat-as-withdraw".

And in the context of OTC inside AS one can say that OTC use case and community use case that are marking routes to prevent leaking is very much the same, do you agree?
[Bruno] Not sure what your point is. I don't agree in the general case:
- community allows for very flexible usage, including having an effect on route selection or installation
- OTC is defined to not be used inside iBGP hence is guaranteed to have no effect on route selection or installation within the AS

And btw, getting back to your original example, how your proposal will help to prevent loops if for some reason the internal sessions are configured as eBGP with private ASNs?
[Bruno] Not sure what you mean by "internal session configured as eBGP". A priori, if you configure eBGP you have an AS boundary and you may filter/change preference of routes on this boundary. (without creating loops)

Your last suggestion that restricts route advertisement in all directions including Customers may improve the situation but in the partial deploy scenario still may lead to hard to debug issues when routes with malformed attribute will travel beyond single administrative domain.
[Bruno] I'm not sure to see your case:
- if the ASBR supports OTC, the proposal would be to filter the route on all eBGP sessions hence the malformed attribute will not travel beyond single administrative domain
- if the ASBR does not support OTC, by definition of optional transitive, it will propagate the route and the malformed attributes regardless of the error handling specified for OTC.

--Bruno

ср, 16 февр. 2022 г. в 17:18, <[email-masked]<mailto:[email-masked]>>:
Hi Sriram,

Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 15, 2022 11:52 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>; Alexander Azimov <[email-masked]<mailto:[email-masked]>>; Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Hi Bruno,

Thanks.

Sriram

Thank you.

--
Best regards,
Alexander Azimov

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 18 Feb 2022 00:44:31 +0300

Bruno,

CLUSTER_LIST is an optional non-transitive attribute. It makes quite
reasonable to have different processing for iBGP and eBGP.
OTC, is an optional transitive attribute with an effect on the routing
selection process. So, I don't feel that CLUSTER_LIST is a good reference.

The common way to use communities (RFC1997 or RFC8092) is an action upon
receipt from eBGP neighbor, optional additional marking, and action at the
export policy with another eBGP neighbor. In that form, there is much in
common with OTC and possible issues that we are discussing.

Let's go back to the side effects of accepting such malformed attributes
from iBGP neighbors while filtering them when received from eBGP neighbors.
Let's say we have a network with two routers R1 and R2 and a route
reflector (RR). Between R1 and R2 there are only P devices - common today
MPLS core.

R1 adds OTC at the receipt and due to bugs in the implementation, it has
incorrect length.
The RR detects it but passes by, while R2 is not upgraded and processes OTC
as an unknown transitive path attribute, just passing it to its eBGP
neighbor.
As a result, such routes may be filtered several hops away. And IMO it will
be quite hard to debug.

Another issue will happen if R2 does a proper check, but due to other BGP
path attributes or igp cost chooses the route with malformed attribute
among possible alternatives.
With the 'treat-as-withdraw' approach it has a chance to pick an
alternative route, with your current suggestion it will be limiting the
number of prefixes that are sent to its customers.

I see your point of getting rid of loops in the case of a network with
multiple IP lookups in the global table while the packet travels through
its core. But I'm not sure if this reason is enough to change error
handling cause it may bring undesirable side effects for modern design
network that uses tunneling. And as the same technique may apply to other
optional transitive attributes such as communities or large communities I
still believe that discussion should be done in terms of updating RFC7606.

ср, 16 февр. 2022 г. в 19:44, <[email-masked]>:

> *From:* Alexander Azimov <[email-masked]>
> *Sent:* Wednesday, February 16, 2022 5:24 PM
> *To:* DECRAENE Bruno INNOV/NET <[email-masked]>
> *Cc:* Sriram, Kotikalapudi (Fed) <[email-masked]>;
> [email-masked]; Alvaro Retana (aretana) <[email-masked]>;
> [email-masked]; Susan Hares <[email-masked]>; Jeffrey Haas <
> [email-masked]>
> *Subject:* Re: ttRE: [Idr] FW: New Version Notification for
>    The error handling of [RFC1997 <https://datatracker.ietf.org/doc/html/rfc1997>] is revised as follows:
>
>
>
> The error handling of [RFC4456
> <https://datatracker.ietf.org/doc/html/rfc4456>] is revised as follows:
>
>
>
> [Bruno] Not sure what your point is. I don’t agree in the general case:
>
> - OTC is defined to not be used inside iBGP hence is guaranteed to have no
> effect on route selection or installation within the AS
>
>
>
> And btw, getting back to your original example, how your proposal will
> help to prevent loops if for some reason the internal sessions are
> configured as eBGP with private ASNs?
>
> [Bruno] Not sure what you mean by “internal session configured as eBGP”. A
> priori, if you configure eBGP you have an AS boundary and you may
> filter/change preference of routes on this boundary. (without creating
> loops)
>
>
> [Bruno] I’m not sure to see your case:
>
> - if the ASBR supports OTC, the proposal would be to filter the route on
> all eBGP sessions hence the malformed attribute will not travel beyond
> single administrative domain
>
> - if the ASBR does not support OTC, by definition of optional transitive,
> it will propagate the route and the malformed attributes regardless of the
> error handling specified for OTC.
>
>
>
> --Bruno
>
>
>

-- 
Best regards,
Alexander Azimov

---

From: <[email-masked]>
Date: Fri, 18 Feb 2022 10:30:02 +0000

Alexander,

TL;DR: If an AS using tunneling between ASBRs there is no risk of forwarding loops due to inconsistent IBGP routes. If not, there are. AFAIK this spec address the Internet and needs to also address ASes using hop by hop IP forwarding.

Orange Restricted
Sent: Thursday, February 17, 2022 10:45 PM

Bruno,

CLUSTER_LIST is an optional non-transitive attribute. It makes quite reasonable to have different processing for iBGP and eBGP.
OTC, is an optional transitive attribute with an effect on the routing selection process. So, I don't feel that CLUSTER_LIST is a good reference.
[Bruno] The question was whether RFC7606 allowed for different behavior based on iBGP or eBGP. Note also that RFC 4271 decision process makes a difference between iBGP and eBGP: the reason is that in order to avoid forwarding loops inside the AS we need routing consistency within the AS, while on EBGP boundary we are free to filter routes without risk of loops.
https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.1

The common way to use communities (RFC1997 or RFC8092) is an action upon receipt from eBGP neighbor, optional additional marking, and action at the export policy with another eBGP neighbor. In that form, there is much in common with OTC and possible issues that we are discussing.

Let's go back to the side effects of accepting such malformed attributes from iBGP neighbors while filtering them when received from eBGP neighbors.
Let's say we have a network with two routers R1 and R2 and a route reflector (RR). Between R1 and R2 there are only P devices - common today MPLS core.

R1 adds OTC at the receipt and due to bugs in the implementation, it has incorrect length.
The RR detects it but passes by, while R2 is not upgraded and processes OTC as an unknown transitive path attribute, just passing it to its eBGP neighbor.
As a result, such routes may be filtered several hops away. And IMO it will be quite hard to debug.
[Bruno] As OTC is a transitive attribute, what you describe in the specific case of error, happens much more generally (e.g. RR does not support OTC). So you are essentially saying that OTC "is quite hard to debug" at least while not universally supported. (5-10 years is the typical duration IMHO, assuming success)

Another issue will happen if R2 does a proper check, but due to other BGP path attributes or igp cost chooses the route with malformed attribute among possible alternatives.
With the 'treat-as-withdraw' approach it has a chance to pick an alternative route, with your current suggestion it will be limiting the number of prefixes that are sent to its customers.
[Bruno] In your AS using tunneling, hence not subject to forwarding loops inside the AS, you are free to add a policy to depref/filter such a route. But in the general case, this is not safe.

I see your point of getting rid of loops in the case of a network with multiple IP lookups in the global table while the packet travels through its core. But I'm not sure if this reason is enough to change error handling cause it may bring undesirable side effects for modern design network that uses tunneling.
[Bruno]
- First I don't agree that "modern" networks use tunneling and hence we can design a solution specifically for the networks using tunneling and don't address the IP networks doing hop by hop routing (especially as we are talking about the Internet using IP.)
- Now if you do want to restrict the solution to network using tunnels, do say so in the spec, and handle the consequences.

And as the same technique may apply to other optional transitive attributes such as communities or large communities I still believe that discussion should be done in terms of updating RFC7606.
[Bruno] OTC is a special case as the attribute is not considered within the AS (by design and enforced in the standard track document). Community are different and more general tools.

--Brunp

ср, 16 февр. 2022 г. в 19:44, <[email-masked]<mailto:[email-masked]>>:
Alexander,

Orange Restricted
From: Alexander Azimov <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 16, 2022 5:24 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>; Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Subject: Re: ttRE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Bruno,

--Bruno

Orange Restricted

Hi Bruno,

Thanks.

Sriram

Thank you.

--
Best regards,
Alexander Azimov

Thank you.

--
Best regards,
Alexander Azimov

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 18 Feb 2022 16:19:46 +0300

Bruno,

Please see my comments below.

пт, 18 февр. 2022 г. в 13:30, <[email-masked]>:

> TL;DR: If an AS using tunneling between ASBRs there is no risk of
> forwarding loops due to inconsistent IBGP routes. If not, there are. AFAIK
> this spec address the Internet and needs to also address ASes using hop
> by hop IP forwarding.
>
>
>
>
>
> Orange Restricted
>
> *Sent:* Thursday, February 17, 2022 10:45 PM
> [Bruno] The question was whether RFC7606 allowed for different behavior
> based on iBGP or eBGP. Note also that RFC 4271 decision process makes a
> difference between iBGP and eBGP: the reason is that in order to avoid
> forwarding loops inside the AS we need routing consistency within the AS,
> while on EBGP boundary we are free to filter routes without risk of loops.
>
I believe that this section is about possible issues with priority loops,
not syntax checks of the attributes and further error handling.

> receipt from eBGP neighbor, optional additional marking, and action at
> the export policy with another eBGP neighbor. In that form, there is much
> in common with OTC and possible issues that we are discussing.
>
>
>
> The RR detects it but passes by, while R2 is not upgraded and
> processes OTC as an unknown transitive path attribute, just passing it to
> its eBGP neighbor.
>
> [Bruno] As OTC is a transitive attribute, what you describe in the
> specific case of error, happens much more generally (e.g. RR does not
> support OTC). So you are essentially saying that OTC “is quite hard to
> debug” at least while not universally supported. (5-10 years is the typical
> duration IMHO, assuming success)
>
You misunderstand my point.
My idea is that if anything except treat-as-withdraw is applied to the path
attribute that affects the routing decision process it increases the
likelihood that a route with a malformed attribute will be propagated
beyond AS boundaries and thus such an issue will be much harder to debug.
Especially at the state of early adoption. And I can't agree that OTC is a
special case here.

> [Bruno] In your AS using tunneling, hence not subject to forwarding loops
> inside the AS, you are free to add a policy to depref/filter such a
> route. But in the general case, this is not safe.
>
It depends on what you mean by the term 'safe'. One can say that any
attribute that has an effect on the routing decision process that
follows the 'treat-as-withdraw' approach is unsafe for a network with
hop-by-hop IP lookups. And your recent experience with forwarding loops
provides evidence for this.

At the same time solutions such as we have discussed above have their own
trade-offs, so there is no 'safe for all' option. And again this has
nothing special with OTC.

> network that uses tunneling.
>
> [Bruno]
>
> - First I don’t agree that “modern” networks use tunneling and hence we
> can design a solution specifically for the networks using tunneling and
> don’t address the IP networks doing hop by hop routing (especially as we
> are talking about the Internet using IP.)
>
> - Now if you do want to restrict the solution to network using tunnels, do
> say so in the spec, and handle the consequences.
>
No, I do not have in mind to limit the scope. I'm sorry if you took the
word 'modern' personally, I didn't have it in mind either.
But I still believe that RFC7606 is quite enough to describe possible
consequences for a network that intentionally makes multiple IP lookups in
its core. Maybe its Operational Considerations section can be strengthened by
adding an abstract that tunneling prevents forwarding loops from happening.

> And as the same technique may apply to other optional transitive
> attributes such as communities or large communities I still believe that
> discussion should be done in terms of updating RFC7606.
>
> [Bruno] OTC is a special case as the attribute is not considered within
> the AS (by design and enforced in the standard track document). Community
> are different and more general tools.
>
But they can trigger the forwarding loops, can't they? The stripping of the
community attribute inside AS is unsafe for similar reasons since today
communities are widely used to prevent networks from leaking. But you may
have proposed the same do-not-export approach to eBGP neighbors making them
safer for your network environment. And then you have to update RFC7606.

---

From: <[email-masked]>
Date: Fri, 18 Feb 2022 15:17:42 +0000

Alexander,

I'm not sure that we are converging.
High level status is that on my side I'm fine with current version (-22) hence if you can also live with -22 we are good.

More line [Bruno2]

Orange Restricted
Sent: Friday, February 18, 2022 2:20 PM

Bruno,

пт, 18 февр. 2022 г. в 13:30, <[email-masked]<mailto:[email-masked]>>:
Alexander,

Orange Restricted

Bruno,

I believe that this section is about possible issues with priority loops, not syntax checks of the attributes and further error handling.

My idea is that if anything except treat-as-withdraw is applied to the path attribute that affects the routing decision process it increases the likelihood that a route with a malformed attribute will be propagated beyond AS boundaries and thus such an issue will be much harder to debug. Especially at the state of early adoption. And I can't agree that OTC is a special case here.

[Bruno2] The malformed attribute is unlikely to propagate beyond AS boundaries as :
- on inbound, treat-as-withdraw is performed on eBGP, effectively filtering both the attribute and the route.
- on outbound, it's not advertised to Providers, Peers, RS. In order to cover the missing Customer case, I would propose to also not advertise the route to Customers if the length of OTC is not 4.
In such case, we would have a double filtering (outbound and inbound).

Another issue will happen if R2 does a proper check, but due to other BGP path attributes or igp cost chooses the route with malformed attribute among possible alternatives.
With the 'treat-as-withdraw' approach it has a chance to pick an alternative route, with your current suggestion it will be limiting the number of prefixes that are sent to its customers.
[Bruno] In your AS using tunneling, hence not subject to forwarding loops inside the AS, you are free to add a policy to depref/filter such a route. But in the general case, this is not safe.
It depends on what you mean by the term 'safe'. One can say that any attribute that has an effect on the routing decision process that follows the 'treat-as-withdraw' approach is unsafe for a network with hop-by-hop IP lookups. And your recent experience with forwarding loops provides evidence for this.

At the same time solutions such as we have discussed above have their own trade-offs, so there is no 'safe for all' option. And again this has nothing special with OTC.

[Bruno2] Yes there is something special with OTC: OTC is not used for IBGP. It does not have to be even read. IMHO, for IBGP the 2 valid options with their tradeoff are
a) attribute discard. Pro: remove error as early as possible, Jeff's point IINM. Con: loss of the attribute and hence its feature (leak prevention)
b) don't read and don't check for error (tradeoff is reversed)

I see your point of getting rid of loops in the case of a network with multiple IP lookups in the global table while the packet travels through its core. But I'm not sure if this reason is enough to change error handling cause it may bring undesirable side effects for modern design network that uses tunneling.
[Bruno]
- First I don't agree that "modern" networks use tunneling and hence we can design a solution specifically for the networks using tunneling and don't address the IP networks doing hop by hop routing (especially as we are talking about the Internet using IP.)
- Now if you do want to restrict the solution to network using tunnels, do say so in the spec, and handle the consequences.
No, I do not have in mind to limit the scope. I'm sorry if you took the word 'modern' personally, I didn't have it in mind either.
But I still believe that RFC7606 is quite enough to describe possible consequences for a network that intentionally makes multiple IP lookups in its core. Maybe its Operational Considerations section can be strengthened by adding an abstract that tunneling prevents forwarding loops from happening.

And as the same technique may apply to other optional transitive attributes such as communities or large communities I still believe that discussion should be done in terms of updating RFC7606.
[Bruno] OTC is a special case as the attribute is not considered within the AS (by design and enforced in the standard track document). Community are different and more general tools.
But they can trigger the forwarding loops, can't they? The stripping of the community attribute inside AS is unsafe for similar reasons since today communities are widely used to prevent networks from leaking. But you may have proposed the same do-not-export approach to eBGP neighbors making them safer for your network environment. And then you have to update RFC7606.
[Bruno2] Communities are very general purpose tools so error handling covers the worst case. OTC has very specific rule for IBGP (not used) hence error handling case use that.

--Bruno

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sun, 20 Feb 2022 18:17:59 +0000

Hi Bruno,

>High level status is that on my side I'm fine with current version (-22) hence if you can also live with -22 we are good.

Alexander and I think that the only viable solution for error handling for the malformed OTC case in IBGP is treat-as-withdraw. The attached figure (.pdf) provides an illustration and explanations. Let us know if you agree.

We feel that the data-loop scenario with malformed OTC has low to very low probability because it requires *all* of the following conditions to be *simultaneously* true:

1. An implementation has an error that causes the OTC length value to be not 4. (prob. = p1)

2. The same implementation has a second error that causes the OTC value to have incorrect #octets to match with the incorrect length value. (prob. = p2)

3. AS in consideration has partial/inconsistent deployment of OTC (at routers/ASBRs within the AS). (prob. = p3)

4. There are no alternate routes available that are free of a malformed OTC. (prob. = p4)

5. The IBGP topology and the data link topology between routers do not match. (prob. = p5)

6. No data tunneling is used to match the data link topology with the IBGP topology. (prob. = p6)
      
The total probability for the data-loop scenario to occur = p1*p2*p3*p4*p5*p6. 

You may pick some reasonable numbers for the pi values and see what it works to be.

RFC 7606 also comments about the expected rarity of data/forwarding loops: 
   
   While lamentable, this issue is expected to be rare in
   practice, and, more importantly, is seen as less problematic than the
   session-reset behavior it replaces.

RFC 7606 goes on to include the following advice in "Operational Considerations":

   When a malformed attribute is indeed detected over an IBGP session,
   we recommend that routes with the malformed attribute be identified
   and traced back to the ingress router in the network where the routes
   were sourced or received externally and then a filter be applied on
   the ingress router to prevent the routes from being sourced or
   received.  This will help maintain routing consistency in the
   network.

Thank you.

Sriram / Alexander

---

From: <[email-masked]>
Date: Tue, 22 Feb 2022 15:32:49 +0000

Hi Sriram,

> Sent: Sunday, February 20, 2022 7:18 PM
> Cc: [email-masked]; Alvaro Retana (aretana) <[email-masked]>; Susan Hares
> <[email-masked]>; Jeffrey Haas <[email-masked]>; Alexander Azimov
> <[email-masked]>
> Subject: RE: ttRE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-
> policy-22.txt
> 
> Hi Bruno,
> 
> Alexander and I think that the only viable solution for error handling for the
> malformed OTC case in IBGP is treat-as-withdraw.

1) the error handling in -22 is viable. (or you have not demonstrated that it is not)
2) OTC is not acted upon on IBGP (i.e. transparent). Why would you want to use a more disruptive reaction (treat-as-withdraw) while one could either not read the OTC/no check for the error or perform attribute discard (for which the only drawback is loosing the OTC feature which seem reasonable given that the OTC attribute is incorrect)

> The attached figure (.pdf)
> provides an illustration and explanations. Let us know if you agree.
> 
> We feel that the data-loop scenario with malformed OTC has low to very low
> probability because it requires *all* of the following conditions to be
> *simultaneously* true:
> 
> 2. The same implementation has a second error that causes the OTC value to have
> incorrect #octets to match with the incorrect length value. (prob. = p2)

"1" and "2" is mostly the same case of error, at least the one we are discussing as if "2" condition is not met, the receiver loose sync of the BGP session and the only reaction is session reset. Again, this is not a theoretical case, one vendor has recently done this (both "1" and "2" for the ELC capability) 

Also there are other cases of error cause by a single faulty implementation: it receive an OTC with length 4 but believe length should have been 5 to be correct. Single bug.

> 3. AS in consideration has partial/inconsistent deployment of OTC (at
> routers/ASBRs within the AS). (prob. = p3)

By definition, first deployment will be incremental. Multiple examples have shown that this can last multiple years (not even considering "legacy" platform that vendors choose no to improve anymore, and not considering that one vendor may chose not to implement this feature).

> 4. There are no alternate routes available that are free of a malformed OTC. (prob.

I'm not sure to see why an alternate route would help. Quite the contrary: with "treat-as-withdraw' withing the AS:
- without alternate route, the packets are dropped 
- with alternate route, the packets may loop (if the BGP Next-Hop points to opposite IGP directions)

Also note that your topology (in the attached PDF) is too simplified as it has not transit IBGP nodes.
In such case there are no forwarding loops. Please consider an AS4 topology with transit IBGP nodes between ASBRs, otherwise you are not even considering the point I'm raising and we are not likely to understand each other.
 
> 5. The IBGP topology and the data link topology between routers do not match.

a) that's seem like extremely common to me: that the case with IBGP full mesh if you don't have a full mesh of physical link (which is extremely expensive in a long distance network); that's also typically the case with route reflector unless all your IBGP transit nodes are route reflectors)
b) I thought we had discussed that the IBGP topology does not matter.

> 6. No data tunneling is used to match the data link topology with the IBGP

Agreed that with tunneling between ASBR, you have not loops. That's a general property and benefit of tunneling. There are also drawbacks. In all cases, you don't want the solution to be restricted to the tunneling case, so error handling needs to work fine with the non-tunneling case.

> You may pick some reasonable numbers for the pi values and see what it works to

I disagree on some point above, but in all cases, probability is above zero. Operators did face and will face BGP errors. We already had this discussion for RFC 7606. Why would you want a more disruptive error handling approach?
Also, if you believe the probably of error is so low, why do you care so much about the type of error handling? You will never face it is the implementations are good enough and tested enough.

>    received.  This will help maintain routing consistency in the

Sure some BGP errors will trigger significant negative impacts.
That does not mean that we should not try to reduce the impacts.

Orange Restricted

---

From: <[email-masked]>
Date: Tue, 22 Feb 2022 18:29:21 +0000

Hi Sriram,

A possible path providing for more flexibility could be to have a well-known community set to routes having the OTC attribute in error.
Then each operator could define its own behavior based on routemap (e.g. filtering or lowering preference, on IBGP transit nodes or ASBR or over EBGP sessions...)
The concept could be generalized for multiple/all attributes by setting a set of 255 communities.
Having a non-transitive community would probably help on the security aspect, but would be for further discussion.

Regards,
--Bruno

Orange Restricted

> -----Original Message-----
> From: Idr <[email-masked]> On Behalf Of [email-masked]
> Sent: Tuesday, February 22, 2022 4:33 PM
> To: Sriram, Kotikalapudi (Fed) <[email-masked]>
> Cc: [email-masked]; Susan Hares <[email-masked]>; Alvaro Retana (aretana)
> <[email-masked]>
> Subject: Re: [Idr] ttRE: FW: New Version Notification for draft-ietf-idr-bgp-open-
> policy-22.txt
> 
> Hi Sriram,
> 
> 
> 
> > >High level status is that on my side I'm fine with current version (-22) hence if
> you
> > can also live with -22 we are good.
> >
> 2) OTC is not acted upon on IBGP (i.e. transparent). Why would you want to use a
> more disruptive reaction (treat-as-withdraw) while one could either not read the
> OTC/no check for the error or perform attribute discard (for which the only
> drawback is loosing the OTC feature which seem reasonable given that the OTC
> attribute is incorrect)
> 
> 
> "1" and "2" is mostly the same case of error, at least the one we are discussing as
> if "2" condition is not met, the receiver loose sync of the BGP session and the
> only reaction is session reset. Again, this is not a theoretical case, one vendor has
> recently done this (both "1" and "2" for the ELC capability)
> 
> Also there are other cases of error cause by a single faulty implementation: it
> receive an OTC with length 4 but believe length should have been 5 to be correct.
> Single bug.
> 
> 
> By definition, first deployment will be incremental. Multiple examples have shown
> that this can last multiple years (not even considering "legacy" platform that
> vendors choose no to improve anymore, and not considering that one vendor may
> chose not to implement this feature).
> 
> 
> > 4. There are no alternate routes available that are free of a malformed OTC.
> (prob.
> > = p4)
> 
> In such case there are no forwarding loops. Please consider an AS4 topology with
> transit IBGP nodes between ASBRs, otherwise you are not even considering the
> point I'm raising and we are not likely to understand each other.
> 
> a) that's seem like extremely common to me: that the case with IBGP full mesh if
> you don't have a full mesh of physical link (which is extremely expensive in a long
> distance network); that's also typically the case with route reflector unless all your
> IBGP transit nodes are route reflectors)
> Agreed that with tunneling between ASBR, you have not loops. That's a general
> property and benefit of tunneling. There are also drawbacks. In all cases, you don't
> want the solution to be restricted to the tunneling case, so error handling needs to
> work fine with the non-tunneling case.
> 
> 
> > You may pick some reasonable numbers for the pi values and see what it works
> to
> > be.
> 
> I disagree on some point above, but in all cases, probability is above zero.
> Operators did face and will face BGP errors. We already had this discussion for
> RFC 7606. Why would you want a more disruptive error handling approach?
> Also, if you believe the probably of error is so low, why do you care so much
> about the type of error handling? You will never face it is the implementations are
> good enough and tested enough.
> 
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 25 Feb 2022 09:25:02 -0500

Bruno: 

One question which I am pulling to the front: 

1) Why disable length checks? 

Your comment : 

[Bruno2] First step that RFC7606 does is to define (i.e. choose) what
constitute an error. We could define that length is not checked for IBGP
because we don't care about the content (or even the attribute).
Alternatively, I'm also fine with attribute discard if we consider that the
attribute is in error and hence could not be trusted.

My point:  Length checks in RFC7606 seem basic sanity check for any message.

After that point, I am fine the remaining being specific to a draft.   For
example, OTC for IBGP can be tossed out after it is determined to have a
valid length. 

Did I miss some other reason.  

Thanks, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 16, 2022 9:19 AM
To: Sriram, Kotikalapudi (Fed)
Cc: [email-masked]; [email-masked]; Alvaro Retana (aretana); Susan Hares
Subject: [Idr] ttRE: FW: New Version Notification for
draft-ietf-idr-bgp-open-policy-22.txt

Hi Sriram,

 

Orange Restricted

From: Sriram, Kotikalapudi (Fed) <[email-masked]> 
Sent: Tuesday, February 15, 2022 11:52 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; Alexander Azimov
<[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]; Alvaro Retana (aretana) <[email-masked]>;
[email-masked]; Susan Hares <[email-masked]>
Subject: RE: [Idr] FW: New Version Notification for
draft-ietf-idr-bgp-open-policy-22.txt

Hi Bruno,

https://datatracker.ietf.org/doc/html/rfc7606#section-8
<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Frfc7606%23section-8&data=04%7C01%7Ckotikalapudi.s
riram%40nist.gov%7Cb7a059d3cee145ca531c08d9f0a3c35f%7C2ab5d82fd8fa4797a93e05
4655c61dec%7C1%7C0%7C637805408436586543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fsbz%2B8
gTR8c0r94m4SoaamR4O%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. 

   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.

[Bruno2] First step that RFC7606 does is to define (i.e. choose) what
constitute an error. We could define that length is not checked for IBGP
because we don't care about the content (or even the attribute).
Alternatively, I'm also fine with attribute discard if we consider that the
attribute is in error and hence could not be trusted.

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

[Bruno2] 1) For IBGP, OTC attribute has no effect on route selection and
installation. 2) Since you seem to be calling for "treat-as-withdraw", I
would argue that "treat-as-withdraw" has also an effect on route selection
or installation, and a bigger one. So it's not really safer in term of side
effect.

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

[Bruno2] It's discussed in the context as session reset, but the cause is
the optional transitive attribute. Cf following text which only refers to
the type of attribute and not the action taken

   manyfold.

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

[Bruno2] If this were true, we could not define the OTC as an optional
transitive attribute, because essentially some routers will not look at OTC.
Pick your 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). 

[Bruno2] 1) That's not the path chosen by RFC 7606 in case of a length
error. 2) I would find debatable to assume an error on a field (type) when
you don't see an error on this field. TLV construct provides hierarchy: I
agree that what is inside the TLV (i.e. after/below the error) can't be
trusted; but for what is before the error, there is little to no reason to
assume an error (and if we do, we could imagine anything and in particular
an attribute for which the error handling is "session reset".)

[Sriram] Then must it be propagated from iBGP to eBGP (in the ASBR) and then
to eBGP neighbors? 

[Bruno2] Current text proposes to _not_ propagate to eBGP neighbors except
for Customer. If length is wrong, I would be fine to also not propagate to
Customerif you find this better.

--Bruno

Thanks.

Sriram

____________________________________________________________________________
_____________________________________________
 
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: <[email-masked]>
Date: Fri, 25 Feb 2022 17:17:27 +0000

Hi Sue,

Thanks for your email.
Please see inline [Bruno3]

On a side note, I'm not even sure that the feature needs the attribute to encode an AS number:
The AS number seems to be only checked in step "Ingress.2" when received from a Peer.  However, there seem to be only 2 cases:
- if the EBGP neighbor supports OTC, it won't send the route if it's a leak (OTC is present), so no need to double check on receipt as we won't receive the route
- if the EBGP neighbor does not support OTC, it won't add the OTC with its own AS number, so no need to check for this specific AS number an OTC would not have this AS number.

Also, doesn't leaking the AS number in the OTC reveal some business relationship that may be private? The security section does not seem to say a word about this.

From: Susan Hares <[email-masked]>
Sent: Friday, February 25, 2022 3:25 PM

Bruno:

  1.  Why disable length checks?

[Bruno3] Because on IBGP we don't even need to read this attribute and there seem to be difficulties about defining how to react to error. So not checking is possible and avoid the difficult discussion.
My preference would be to check and perform attribute discard on IBGP. But some want to keep the OTC feature even though the attribute is bogus (while the vast majority of routes are not leak so the probabilities would be that the route is useful and should be kept, rather than treat-as-withdraw).

Your comment :

My point:  Length checks in RFC7606 seem basic sanity check for any message.
[Bruno3] Sure. That being said, for the CLUSTER_LIST attribute, there is a different handling for EBGP and IBGP with IBGP checking for the length while EBGP not checking the length https://datatracker.ietf.org/doc/html/rfc7606#section-7.10

After that point, I am fine the remaining being specific to a draft.   For example, OTC for IBGP can be tossed out after it is determined to have a valid length.
[Bruno3] I'm assuming that you meant "is determined to have an _invalid_ length".

--Bruno

Thanks, Sue

Orange Restricted
From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, February 16, 2022 9:19 AM
To: Sriram, Kotikalapudi (Fed)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana); Susan Hares
Subject: [Idr] ttRE: FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Hi Sriram,

Orange Restricted

Hi Bruno,

Thanks.

Sriram

Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 25 Feb 2022 17:30:41 -0500

Bruno,

I'll be summarizing the Chairs discussion in next reply, but wanted to
address this specific point:

> - if the EBGP neighbor supports OTC, it won't send the route if it's a leak (OTC is present), so no need to double check on receipt as we won't receive the route

Agreed.

> - if the EBGP neighbor does not support OTC, it won't add the OTC with its own AS number, so no need to check for this specific AS number an OTC would not have this AS number.

The desired Egress procedure is to make sure a Peer role has received an OTC
attribute.

Peer Roles should not propagate routes they receive from other Peers.

If a Peer Role Ingress receives an OTC route, it needs to choose whether
that route is one that the Peer is propagating from itself or its Customer
roles or whether this is actually a leak that wasn't enforced due to lack of
support.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 25 Feb 2022 20:03:06 -0500

Bruno: 

The idr-chairs discussed your proposals.  Since Jeff kindly led the
discussion this week, Jeff is posting the IDR chairs response.   

As Jeff mentioned, we will be glad to sponsor a revision for RFC7606. 

Since you were kind enough to respond to me quickly, I have responded to
your questions from my view

As Jeff mentioned, we will be glad to sponsor a revision for RFC7606. 

Please let us know if this consensus call works for you. 

Again, Jeff, Keyur and I really appreciate you digging into the error cases.

We hope that other people will carefully read this discussion, and 

think about RFC7606.   If you wish to have a short presentation discussing
this topic 

at the next IETF, please let us know. 

Sue 

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 25, 2022 12:17 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Alvaro Retana (aretana)'; 'Sriram,
Kotikalapudi (Fed)'
Subject: RE: [Idr] ttRE: FW: New Version Notification for
draft-ietf-idr-bgp-open-policy-22.txt

Hi Sue,

Thanks for your email.

On a side note, I'm not even sure that the feature needs the attribute to
encode an AS number:

The AS number seems to be only checked in step "Ingress.2" when received
from a Peer.  However, there seem to be only 2 cases:

- if the EBGP neighbor supports OTC, it won't send the route if it's a leak
(OTC is present), so no need to double check on receipt as we won't receive
the route

- if the EBGP neighbor does not support OTC, it won't add the OTC with its
own AS number, so no need to check for this specific AS number an OTC would
not have this AS number.

Also, doesn't leaking the AS number in the OTC reveal some business
relationship that may be private? The security section does not seem to say
a word about this.

[Sue]:  [personal opinion]:  

Yes, it does reveal something.  The security section should mention it.  

Two caveats:  

1) Does it help operators to realize this point?  - If so, suggest some
wording that will be effective for the operators. 

2) Alvaro has reached an agreement on the text with the IESG.  We will need
Alvaro to approve any text changes as Ok with IESG's intent.  

Bruno: 

[Bruno3] Because on IBGP we don't even need to read this attribute and there
seem to be difficulties about defining how to react to error. So not
checking is possible and avoid the difficult discussion.

My preference would be to check and perform attribute discard on IBGP. But
some want to keep the OTC feature even though the attribute is bogus (while
the vast majority of routes are not leak so the probabilities would be that
the route is useful and should be kept, rather than treat-as-withdraw).

[Sue]: Jeff clearly states the chairs reasoning. 

 On IBGP, we need to check and  "treat-as-withdraw" behavior.  

I think this addresses your concern and the IDR chair's concern. 

Your comment : 

[Bruno3] Sure. That being said, for the CLUSTER_LIST attribute, there is a
different handling for EBGP and IBGP with IBGP checking for the length while
EBGP not checking the length
<https://datatracker.ietf.org/doc/html/rfc7606#section-7.10>
https://datatracker.ietf.org/doc/html/rfc7606#section-7.10

[sue]: I agree that the cluster list attribute has a different handling for
E-BGP and I-BGP. 

We discussed the pros/cons for OTC, but we think the "treat as withdraw' is
best. 

[Bruno3] I'm assuming that you meant "is determined to have an _invalid_
length".

[Sue]: First test for valid length.  If invalid, treat as withdraw.  

--Bruno

Thanks, Sue 

Orange Restricted

Hi Sriram,

 

Orange Restricted

Hi Bruno,

   detailed in Section 2.

   manyfold.

 

--Bruno

Thanks.

Sriram