Subject: Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 6 Jan 2022 16:00:01 +0000

Jeff,
Thank you.

>This is already a fault per RFC 4271, Section 6.3:
>
>:    If any attribute appears more than once in the UPDATE message, then
>:    the Error Subcode MUST be set to Malformed Attribute List.

RFC 7606 (Section 3, item g in the list) updates the above:
       ... If any other attribute (whether
       recognized or unrecognized) appears more than once in an UPDATE
       message, then all the occurrences of the attribute other than the
       first one SHALL be discarded and the UPDATE message will continue
       to be processed.

>My recommendations:
> - In 4.2, change the voicing to say "the OTC Attribute has a value"
> - Delete the "Correct implementation" paragraph as unnecessary text.

Your first suggestion above is good and accepted.
Regarding your second suggestion above, we can either
(1) Delete the paragraph implicitly assuming implementations will discard "all the occurrences of the attribute other than the first one".
or,
(2) Explicitly state the expected behavior by rewording the paragraph in question as follows:

   Correct implementation of the procedures specified in this document
   is not expected to result in the presence of multiple OTC Attributes
   in an UPDATE.  However, if an eBGP speaker receives multiple OTC
   Attributes in an UPDATE message, then all the occurrences of
   the attribute other than the first one SHALL be discarded and
   the UPDATE message will continue to be processed [RFC7606].

We'll await your further advice. Maybe Alvaro would have a suggestion as well.
Sriram
----------------------------------------------
From: Jeff Haas

A few comments from things I noticed while reviewing the open-policy draft
while working through current threads:

Section 4.2:

:    2.  If a route with the OTC Attribute is received from a Peer and at
:        least one of the OTC Attributes has a value that is not equal to
:        the remote (i.e., Peer's) AS number, then it is a route leak and
:        MUST be considered ineligible.

By the definition of the path attribute's length field, there can only be
one of them.

The text recognizes this point later:

:    If an eBGP speaker receives an UPDATE with an OTC Attribute with a
:    length different from 4 octets, then the UPDATE SHALL be considered
:    malformed.  If malformed, the UPDATE message SHALL be handled using
:    the approach of "treat-as-withdraw" [RFC7606].

But:

:    Correct implementation of the procedures specified in this document
:    is not expected to result in the presence of multiple OTC Attributes
:    in an UPDATE.  However, if an eBGP speaker receives multiple OTC
:    Attributes with a route, then the only difference in the processing
:    is in Step 2 of the ingress policy.

This is already a fault per RFC 4271, Section 6.3:

:    If any attribute appears more than once in the UPDATE message, then
:    the Error Subcode MUST be set to Malformed Attribute List.

My recommendations:
- In 4.2, change the voicing to say "the OTC Attribute has a value"
- Delete the "Correct implementation" paragraph as unnecessary text.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Jan 2022 11:18:15 -0500

Sriram,

Thanks for reminding me of the related RFC 7606 text.

In general, what we try to avoid doing is restating procedures from core documents.  Errors tend to creep in that way leading to ambiguity for developers.

My recommendation is to simply remove the paragraph.  If you have strong motivation (and can explain why) to include something on the matter at all, my suggestion is to simply add a sentence stating, "Duplicate instances of the Path Attribute MUST be handled by existing BGP error handling procedures; see RFC 7606, section 3(g)."

-- Jeff

> On Jan 6, 2022, at 11:00 AM, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
> 
> Jeff,
> 
> Thank you.
> 
>  
> 
>        … If any other attribute (whether
> 
> (1) Delete the paragraph implicitly assuming implementations will discard “all the occurrences of the attribute other than the first one”.
> 
> or, 
> 
> We’ll await your further advice. Maybe Alvaro would have a suggestion as well.
> 
> Sriram
>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 6 Jan 2022 10:49:22 -0800

FWIW, I agree with Jeff.

Alvaro.

On January 6, 2022 at 11:18:17 AM, Jeffrey Haas ([email-masked]) wrote:

Sriram,

In general, what we try to avoid doing is restating procedures from core
documents.  Errors tend to creep in that way leading to ambiguity for
developers.

My recommendation is to simply remove the paragraph.  If you have strong
motivation (and can explain why) to include something on the matter at all,
my suggestion is to simply add a sentence stating, "Duplicate instances of
the Path Attribute MUST be handled by existing BGP error handling
procedures; see RFC 7606, section 3(g)."

-- Jeff

On Jan 6, 2022, at 11:00 AM, Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

Jeff,

Thank you.

       to be processed.

(1) Delete the paragraph implicitly assuming implementations will discard
“all the occurrences of the attribute other than the first one”.

or,

(2) Explicitly state the expected behavior by rewording the paragraph in
question as follows:

We’ll await your further advice. Maybe Alvaro would have a suggestion as
well.

Sriram

From: Jeff Haas

Section 4.2:

one of them.

But:

My recommendations:

-- Jeff

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 7 Jan 2022 17:08:13 +0000

Jeff,

>My recommendation is to simply remove the paragraph.

Done. Thanks once again for the good catch.

Sriram

From: Jeffrey Haas <[email-masked]>
Sent: Thursday, January 6, 2022 11:18 AM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: [email-masked]; Alvaro Retana <[email-masked]>; [email-masked]; Alexander Azimov <[email-masked]>
Subject: Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy

Sriram,

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 13:33:52 -0500

Sriram and Jeff: 

Thanks for catching the RFC7606 case. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Friday, January 7, 2022 12:08 PM
To: Jeffrey Haas
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy

Jeff,

Sriram

Sriram,

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 14:05:16 -0500

Sriram and Alex: 

Please make sure to update your implementation report to match -19.txt.   Please let developers know about code point issues.  

Sue 

Jeff,

Sriram

Sriram,

-- Jeff

---

From: Alexander Azimov <[email-masked]>
Date: Mon, 10 Jan 2022 13:38:21 +0300

Eugene Bogomazov have already discussed this issue with maintainers of
BIRD. He will check the status of FRR and update the patch as
soon as we get new code point.

I will try to contact Mikrotik developers, since they have independently
implemented BGP roles in their software.

сб, 8 янв. 2022 г. в 22:05, Susan Hares <[email-masked]>:

> Sriram and Alex:
>
>
>
> Please make sure to update your implementation report to match -19.txt.
>   Please let developers know about code point issues.
>
>
>
> Sue
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Sriram,
> Kotikalapudi (Fed)
> *Sent:* Friday, January 7, 2022 12:08 PM
> *To:* Jeffrey Haas
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy
>
>
>
> Jeff,
>
>
>
> *From:* Jeffrey Haas <[email-masked]>
> *Sent:* Thursday, January 6, 2022 11:18 AM
> *To:* Sriram, Kotikalapudi (Fed) <[email-masked]>
> *Cc:* [email-masked]; Alvaro Retana <[email-masked]>;
> [email-masked]; Alexander Azimov <
> [email-masked]>
> *Subject:* Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy
>
>
>
> Sriram,
>
>
>

-- 
Best regards,
Alexander Azimov

---

From: Alexander Azimov <[email-masked]>
Date: Mon, 10 Jan 2022 18:32:56 +0300

Colleagues,

I got reply from Mikrotik.

At the moment they have only role as configuration parameter, the role
negotiation and OTC are only in plan for implementation, hopefully this
year.
They promised to update their status page accordingly.

For the BIRD and FRR Eugene is planning to send patches to upstreams after
the new code allocation.

-- 
Best regards,
Alexander Azimov

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Jan 2022 12:56:52 -0500

Thanks for letting me know.   I’ll query IANA to see if they have assigned the new code. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Alexander Azimov
Sent: Monday, January 10, 2022 5:38 AM
To: Susan Hares
Cc: idr wg; Sriram, Kotikalapudi (Fed); [email-masked]
Subject: Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy

Eugene Bogomazov have already discussed this issue with maintainers of BIRD. He will check the status of FRR and update the patch as soon as we get new code point.

I will try to contact Mikrotik developers, since they have independently implemented BGP roles in their software.

Sriram and Alex: 

Sue 

Jeff,

Sriram

Sriram,

-- Jeff

 

-- 

Best regards,

Alexander Azimov

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 10 Jan 2022 12:45:42 -0800

Hi!

IANA will assign using the normal process.  In this case, once the document
is approved by the IESG (it is on the Jan/20 Telechat).

If we want an earlier assignment then we’ll have to ask for early
allocation.

I’m not sure that the time difference (of a couple of weeks) will make a
significant difference.

Alvaro.

On January 10, 2022 at 12:57:21 PM, Susan Hares ([email-masked]) wrote:

Thanks for letting me know.   I’ll query IANA to see if they have assigned
the new code.

Sue

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Jan 2022 17:04:29 -0500

Alvaro: 

Will it make a difference to the IESG if the implementations were done using the previous value.  

If it matters for the 1/20/2022 IESG meeting, then we could go for the early allocation and ask the open source people to implement. 

If not,  we can wait. 

What do you think? 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Monday, January 10, 2022 3:46 PM
To: Susan Hares; Alexander Azimov
Cc: idr wg; [email-masked]; Sriram, Kotikalapudi (Fed)
Subject: Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy

Hi!

IANA will assign using the normal process.  In this case, once the document is approved by the IESG (it is on the Jan/20 Telechat).

If we want an earlier assignment then we’ll have to ask for early allocation.  

I’m not sure that the time difference (of a couple of weeks) will make a significant difference.

Alvaro.

Sue

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 10 Jan 2022 14:05:39 -0800

Hi!

No, it won’t make a difference to the IESG.

Thanks!

Alvaro.

On January 10, 2022 at 5:04:37 PM, Susan Hares ([email-masked]) wrote:

Alvaro:

Will it make a difference to the IESG if the implementations were done
using the previous value.

If it matters for the 1/20/2022 IESG meeting, then we could go for the
early allocation and ask the open source people to implement.

If not,  we can wait.

What do you think?

Sue

*From:* Idr [mailto:[email-masked]] *On Behalf Of *Alvaro Retana
*Sent:* Monday, January 10, 2022 3:46 PM
*To:* Susan Hares; Alexander Azimov
*Cc:* idr wg; [email-masked]; Sriram, Kotikalapudi
(Fed)
*Subject:* Re: [Idr] Comments on draft-ietf-idr-bgp-open-policy

Hi!

Alvaro.

Sue