Subject: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 30 Jul 2019 06:37:59 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-idr-bgp-extended-messages-33: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some comment on use of normative language:

1) I know what the intention is here but this normative language is not used correctly (sec 4):
"A BGP speaker
   MAY send Extended Messages to a peer only if the Extended Message
   Capability was advertised by both peers."
This should be a MUST anyway (and moving the "only"):
"A BGP speaker
   MUST only send Extended Messages to a peer if the Extended Message
   Capability was advertised by both peers."
Or you go for the MUST NOT (and maybe even two sentence) to make it crystal clear, e.g.
"A BGP speaker
   MUST NOT send Extended Messages to a peer if the Extended Message
   Capability was not advertised by both peers. A BGP speaker
   MAY send Extended Messages to a peer if the Extended Message
   Capability was advertised by both peers."

2) sec 4:
"If a BGP message with a Length greater than 4,096 octets is received
   by a BGP listener who has not advertised the Extended Message
   Capability, the listener MUST treat this as a malformed message, and
   MUST generate a NOTIFICATION with the Error Subcode set to Bad
   Message Length (see [RFC4271] Sec 6.1)."
If this is specified normatively in RFC4271, you should not use normative language here as well.
I suggest s/MUST/will/

3) sec 4:
s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the neighbor/
and
s/it must be withdrawn from service/it MUST be withdrawn from service/

4) sec 4
"In an iBGP mesh, if BGP Extended Messages are to be advertized, all
   peers MUST advertize the BGP Extended Message capability."
Which action(s) should be taken if that is not the case?

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 30 Jul 2019 10:39:14 -0400

On July 30, 2019 at 9:38:01 AM, Mirja Kühlewind via Datatracker (
[email-masked]) wrote:

Mirja:

Hi!

Thanks for your review.

...

---------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) I know what the intention is here but this normative language is not
used correctly (sec 4):
"A BGP speaker
MAY send Extended Messages to a peer only if the Extended Message
Capability was advertised by both peers."
This should be a MUST anyway (and moving the "only"):
"A BGP speaker
MUST only send Extended Messages to a peer if the Extended Message
Capability was advertised by both peers."
Or you go for the MUST NOT (and maybe even two sentence) to make it crystal
clear, e.g.
"A BGP speaker
MUST NOT send Extended Messages to a peer if the Extended Message
Capability was not advertised by both peers. A BGP speaker
MAY send Extended Messages to a peer if the Extended Message
Capability was advertised by both peers."

This point (and your last one) should be clarified in light of
clarifications to rfc5492 (Capabilities Advertisement) that were discussed
in Montreal last week.  I’ve started a separate thread with the authors.

2) sec 4:
If this is specified normatively in RFC4271, you should not use normative
language here as well.
I suggest s/MUST/will/

3) sec 4:
s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the
neighbor/
and
s/it must be withdrawn from service/it MUST be withdrawn from service/

All the actions on these two points are in fact normatively specified in
rfc4271 (which is the reason for the specific references)…so we should use
non-Normative text in both cases.

IOW: your point in #2 is accurate, but the changes suggested in #3 should
not be applied.

Thanks!!

Alvaro.

4) sec 4

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 30 Jul 2019 16:56:43 +0200

Hi Alvaro,

See below.

> On 30. Jul 2019, at 16:39, Alvaro Retana <[email-masked]> wrote:
> 
> On July 30, 2019 at 9:38:01 AM, Mirja Kühlewind via Datatracker ([email-masked]) wrote:
> 
> Mirja:
> 
> Hi!
> 
> Thanks for your review.
> 
> ...
> This point (and your last one) should be clarified in light of clarifications to rfc5492 (Capabilities Advertisement) that were discussed in Montreal last week.  I’ve started a separate thread with the authors.
> 
> 
> 
>> 2) sec 4: 
>> Message Length (see [RFC4271] Sec 6..1)." 
> All the actions on these two points are in fact normatively specified in rfc4271 (which is the reason for the specific references)…so we should use non-Normative text in both cases.  
> 
> IOW: your point in #2 is accurate, but the changes suggested in #3 should not be applied.
> 
Ah, then I guess #3 should also be s/must/will/ …

Thanks for caring about this!

Mirja

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jul 2019 12:22:02 -0400

Alvaro:

On #3, I’ve not seen the separate thread you’ve started with the authors.  Did I miss something as the shepherd? 

On #2, the Discussion from the WG (over long period of time) suggested that this exact statement was not clearly stated in RFC4271.   

Given that point, we allowed the normative case.  It is a judgment case.  Do you want to engage in an argument pro/con with Mirja on the WG list or do you want to determine at AD level that the text should be non-normative? 

Sue Hares

Shepherd 

From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Tuesday, July 30, 2019 10:39 AM
To: Mirja Kühlewind; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

Mirja:

Hi!

Thanks for your review.

...

2) sec 4: 

3) sec 4: 

Thanks!!

Alvaro.

4) sec 4

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 30 Jul 2019 18:33:16 +0200

Hi Susan,

These are only comments from my side (no discusses), so Alvaro can determine the right solution without me intervening. However, my personal view regarding #2 that if this is not clearly defined in RFC4271, the document should state that and update RFC4271 accordingly.

Mirja

> On 30. Jul 2019, at 18:22, Susan Hares <[email-masked]> wrote:
> 
> Alvaro:
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jul 2019 14:30:50 -0400

Mirja:

Thank you for the email and for caring enough to ask the question.    As an co-author on RFC4271, I had my personal view on this topic.   As a chair, I listened to another opinion. 

I'll follow-up with Alvaro. 

Sue Hares 

-----Original Message-----
From: Mirja Kuehlewind [mailto:[email-masked]] 
Sent: Tuesday, July 30, 2019 12:33 PM
To: Susan Hares
Cc: Alvaro Retana; The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

Hi Susan,

Mirja

> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Idr] Mirja Kühlewind's No Objection on 
> draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)
>  
>> -
>> Capability was not advertised by both peers. A BGP speaker MAY send 
>> Extended Messages to a peer if the Extended Message Capability was 
>> advertised by both peers."
>> s/then it must NOT be sent to the neighbor/then it MUST NOT be sent 
>> to the neighbor/ and s/it must be withdrawn from service/it MUST be 
>> withdrawn from service/

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 30 Jul 2019 15:00:32 -0400

On July 30, 2019 at 12:22:13 PM, Susan Hares ([email-masked]) wrote:

Sue:

Hi!

On #2, the Discussion from the WG (over long period of time) suggested that
this exact statement was not clearly stated in RFC4271.

This is the text that Mirja highlighted:

   If a BGP message with a Length greater than 4,096 octets is received
   by a BGP listener who has not advertised the Extended Message
   Capability, the listener MUST treat this as a malformed message, and
   MUST generate a NOTIFICATION with the Error Subcode set to Bad
   Message Length (see [RFC4271] Sec 6.1).

First of all, if a BGP router doesn't support Extended Messages it means it
doesn't support this document...so we can't Normatively tell them what to
do.

rfc4271/§6.1 (Message Header Error Handling) specifies what to do if, among
other things, the length is greater than 4096...so that would be what the
speaker who doesn't support this document would do.

NEW>
   If a BGP message with a Length greater than 4,096 octets is received
   by a BGP listener who has not advertised the Extended Message
   Capability, the listener will generate a NOTIFICATION with the Error
   Subcode set to Bad Message Length ([RFC4271], Section 6.1).

Thanks!

Alvaro.

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2019 12:05:56 -0700

>    Subcode set to Bad Message Length ([RFC4271], Section 6.1).

ack

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2019 12:51:46 -0700

i believe this is the only outstanding point from mirja's careful review
(tyvm)

> 3) sec 4:
> s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the neighbor/and

i have no problem with this change.  does someone want to make an
argument that 4271 being normative obviates normative language here?

randy

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 30 Jul 2019 16:04:44 -0400

Yes.  These changes are not needed precisely because of rfc4271.

Thanks!

Alvaro.

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2019 13:09:57 -0700

so non-normative for both

    If the message is still too big, then it must not be sent to the
    neighbor (<xref target="RFC4271"/>, Section 9.2).  Additionally, if
    the NLRI was previously advertised to that peer, it must be
    withdrawn from service (<xref target="RFC4271"/>, Section 9.1.3).

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2019 13:51:44 -0700

[ to continue down a rather small and twisty rathole which only leads to
  velveta ]
  
>> 3) sec 4:>> s/then it must NOT be sent to the neighbor/then it MUST
>> NOT be sent to the neighbor/and > s/it must be withdrawn from
>> service/it MUST be withdrawn from service/

btw, i do not entirely buy this

if the draft was phrased

    As specified in <xref target="RFC4271"/>, Section 9.2, if the
    message is still too big, then it MUST NOT be sent to the neighbor.
    Additionally, per <xref target="RFC4271"/>, Section 9.1.3, if the
    NLRI was previously advertised to that peer, it MUST BE withdrawn
    from service.

i.e. normative language might be used because one is directly referring
the same in 4271.

if you buy that, then

    If the message is still too big, then it MUST NOT be sent to the
    neighbor (<xref target="RFC4271"/>, Section 9.2).  Additionally, if
    the NLRI was previously advertised to that peer, it MUST be
    withdrawn from service (<xref target="RFC4271"/>, Section 9.1.3).

is just an english, well american, reconstruction of the same.

but i really do not care much.  so -34 is currently non-normative until
someone tells me otherwise.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2019 18:22:23 -0700

i have pushed -34, as there have been lots of small changes since -33
and iesg readers should not have to trip over old fixed junk, and
instead find new junk.

randy

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Wed, 31 Jul 2019 01:53:00 +0000

Hi, Randy and Alvaro:

Here is a patch that would clarify the capability definition, the issue that I brought up before.
It also include changing "BGP listener" to "BGP speaker" in two places.

Thanks.  -- Enke

*** bgp-large-msg-34.txt.orig	Tue Jul 30 18:24:32 2019
--- bgp-large-msg-34.txt	Tue Jul 30 18:34:07 2019
*************** Internet-Draft      Extended Message sup
*** 120,148 ****
     defined with Capability code 6 and Capability length 0.
  
     To advertise the BGP Extended Message Capability to a peer, a BGP
     speaker uses BGP Capabilities Advertisement [RFC5492].  By
     advertising the BGP Extended Message Capability to a peer, a BGP
!    speaker conveys that it is able to send, receive, and properly
     handle, see Section 4, BGP Extended Messages.
  
-    A peer which does not advertise this capability MUST NOT send BGP
-    Extended Messages, and BGP Extended Messages MUST NOT be sent to it.
- 
     Peers that wish to use the BGP Extended Message capability MUST
     support Error Handling for BGP UPDATE Messages per [RFC7606].
  
  4.  Operation
  
     The Extended Message Capability applies to all messages except for
     the OPEN and KEEPALIVE messages.  The former exception is to reduce
     the complexity of providing backward compatibility.
  
!    A BGP speaker that is capable of sending and receiving BGP Extended
     Messages SHOULD advertise the BGP Extended Message Capability to its
     peers using BGP Capabilities Advertisement [RFC5492].  A BGP speaker
!    MAY send Extended Messages to a peer if the Extended Message
     Capability was received from that peer.
  
     An implementation that advertises the BGP Extended Message capability
     MUST be capable of receiving a message with a Length up to and
     including 65,535 octets.
--- 120,145 ----
     defined with Capability code 6 and Capability length 0.
  
     To advertise the BGP Extended Message Capability to a peer, a BGP
     speaker uses BGP Capabilities Advertisement [RFC5492].  By
     advertising the BGP Extended Message Capability to a peer, a BGP
!    speaker conveys that it is able to receive, and properly
     handle, see Section 4, BGP Extended Messages.
  
     Peers that wish to use the BGP Extended Message capability MUST
     support Error Handling for BGP UPDATE Messages per [RFC7606].
  
  4.  Operation
  
     The Extended Message Capability applies to all messages except for
     the OPEN and KEEPALIVE messages.  The former exception is to reduce
     the complexity of providing backward compatibility.
  
!    A BGP speaker that is capable of receiving BGP Extended
     Messages SHOULD advertise the BGP Extended Message Capability to its
     peers using BGP Capabilities Advertisement [RFC5492].  A BGP speaker
!    MAY send Extended Messages to a peer only if the Extended Message
     Capability was received from that peer.
  
     An implementation that advertises the BGP Extended Message capability
     MUST be capable of receiving a message with a Length up to and
     including 65,535 octets.
*************** Internet-Draft      Extended Message sup
*** 157,168 ****
     4,096 octet pre- Extended Message limit, so as not to require
     downstream routers to decompose for peers that do not support
     Extended Messages.  See Section 8.
  
     If a BGP message with a Length greater than 4,096 octets is received
!    by a BGP listener who has not advertised the Extended Message
!    Capability, the listener will generate a NOTIFICATION with the Error
     Subcode set to Bad Message Length ([RFC4271] Sec 6.1).

  Bush, et al.            Expires January 31, 2020                [Page 3]
--- 154,165 ----
     4,096 octet pre- Extended Message limit, so as not to require
     downstream routers to decompose for peers that do not support
     Extended Messages.  See Section 8.
  
     If a BGP message with a Length greater than 4,096 octets is received
!    by a BGP speaker who has not advertised the Extended Message
!    Capability, the speaker will generate a NOTIFICATION with the Error
     Subcode set to Bad Message Length ([RFC4271] Sec 6.1).

  Bush, et al.            Expires January 31, 2020                [Page 3]
*************** Internet-Draft      Extended Message sup
*** 175,190 ****
     speakers which may not support Extended Messages.  Therefore, an
     announcement in an Extended Message where the size of the attribute
     set plus the NLRI is larger than 4,096 octets may cause lack of
     reachability.
  
!    A BGP speaker with a mixture of peers some of which have advertised
!    the BGP Extended Message capability and some which have not, may
!    receive an UPDATE from one of its capable peers that produces an
     ongoing announcement that is larger than 4,096 octets.  When
     propagating that UPDATE onward to a neighbor which has not advertised
!    the BGP Extended Message capability, the sender SHOULD try to reduce
     the outgoing message size by removing attributes eligible under the
     "attribute discard" approach of [RFC7606].  If the message is still
     too big, then it must not be sent to the neighbor ([RFC4271],
     Section 9.2).  Additionally, if the NLRI was previously advertised to
     that peer, it must be withdrawn from service ([RFC4271],
--- 172,187 ----
     speakers which may not support Extended Messages.  Therefore, an
     announcement in an Extended Message where the size of the attribute
     set plus the NLRI is larger than 4,096 octets may cause lack of
     reachability.
  
!    A BGP speaker that has advertised
!    the BGP Extended Message capability to its peers, may
!    receive an UPDATE from one of its peers that produces an
     ongoing announcement that is larger than 4,096 octets.  When
     propagating that UPDATE onward to a neighbor which has not advertised
!    the BGP Extended Message capability, the speaker SHOULD try to reduce
     the outgoing message size by removing attributes eligible under the
     "attribute discard" approach of [RFC7606].  If the message is still
     too big, then it must not be sent to the neighbor ([RFC4271],
     Section 9.2).  Additionally, if the NLRI was previously advertised to
     that peer, it must be withdrawn from service ([RFC4271],

-----Original Message-----
From: Idr <[email-masked]> on behalf of Randy Bush <[email-masked]>
Date: Tuesday, July 30, 2019 at 6:23 PM
To: Alvaro Retana <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "\"Mirja Kühlewind via Datatracker\"" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr]  Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

    randy
    
    _______________________________________________
    Idr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/idr

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 31 Jul 2019 05:20:11 -0700

On July 30, 2019 at 9:53:36 PM, Enke Chen (enkechen) ([email-masked])
wrote:

Enke:

Hi!

Here is a patch that would clarify the capability definition, the issue
that I brought up before.
It also include changing "BGP listener" to "BGP speaker" in two places.

I looked at the changes and they look good tome.  I think that generalizing
to “speaker” does help.

Thanks!!

Alvaro.

*** bgp-large-msg-34.txt.orig Tue Jul 30 18:24:32
<http://airmail.calendar/2019-07-30 18:24:32 GMT-4> 2019
--- bgp-large-msg-34.txt Tue Jul 30 18:34:07
<http://airmail.calendar/2019-07-30 18:34:07 GMT-4> 2019
*************** Internet-Draft Extended Message sup
*** 120,148 ****
defined with Capability code 6 and Capability length 0.

4. Operation

4. Operation

---

From: Randy Bush <[email-masked]>
Date: Wed, 31 Jul 2019 06:25:22 -0700

thanks enke.  see -35

randy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 31 Jul 2019 11:27:48 -0400

Alvaro and Randy: 

Thank you for starting this message thread this week.   As a professor, I’m in the midst of grading – so I’m online this week. 

The BGP peer receiving the message generates a  NOTIFICATION with a  Message Header Error and a subcode of “Bad message length”  (page 21, p. 30).  Please note the difference in the language.    This language tags the event directly to Event 21: BGPHeaderErr in the BGP FSM (p. 48).  

Text must be: 

New/

   Capability, the listener will generate a NOTIFICATION with the Message Header error 

   and an Error subcode set to Bad Message Length ([RFC4271], Section 6.1).

/

Otherwise, it does not keep the consistency with the BGP FSM. 

Sue 

From: Alvaro Retana [mailto:[email-masked]] 
Sent: Tuesday, July 30, 2019 3:01 PM
To: Susan Hares; Mirja Kühlewind; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

Sue:

Hi!

First of all, if a BGP router doesn't support Extended Messages it means it doesn't support this document...so we can't Normatively tell them what to do.

rfc4271/§6.1 (Message Header Error Handling) specifies what to do if, among other things, the length is greater than 4096...so that would be what the speaker who doesn't support this document would do.

NEW>

 

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 31 Jul 2019 12:01:03 -0400

Enke:

Your point is that a BGP speaker is defined in RFC5492 and a BGP listener is not? 

Cheerily, Susan Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Enke Chen (enkechen)
Sent: Tuesday, July 30, 2019 9:53 PM
To: Randy Bush; Alvaro Retana
Cc: [email-masked]; [email-masked]; [email-masked]; The IESG; "Mirja Kühlewind via Datatracker"
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

Hi, Randy and Alvaro:

Thanks.  -- Enke

  
  
  4.  Operation

  

  
  4.  Operation

  

  

  

-----Original Message-----
From: Idr <[email-masked]> on behalf of Randy Bush <[email-masked]>
Date: Tuesday, July 30, 2019 at 6:23 PM
To: Alvaro Retana <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "\"Mirja Kühlewind via Datatracker\"" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr]  Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

    randy

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Wed, 31 Jul 2019 16:51:20 +0000

Hi, Sue:

As I understand,  the term "BGP speaker" is more commonly used, as in this draft also.

In this draft, there are numerous occurrences of the term "BGP speaker", and two "BGP listener".
It would be good to make them consistency if there is no special reason for a distinction.

Thanks.  -- Enke

-----Original Message-----
From: Susan Hares <[email-masked]>
Date: Wednesday, July 31, 2019 at 9:02 AM
To: "Enke Chen (enkechen)" <[email-masked]>, 'Randy Bush' <[email-masked]>, 'Alvaro Retana' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'The IESG' <[email-masked]>, "'\"Mirja Kühlewind via Datatracker\"'" <[email-masked]>
Subject: RE: [Idr]  Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

    Enke:

    Cheerily, Susan Hares 

    -----Original Message-----
    From: Idr [mailto:[email-masked]] On Behalf Of Enke Chen (enkechen)
    Sent: Tuesday, July 30, 2019 9:53 PM
    To: Randy Bush; Alvaro Retana
    Cc: [email-masked]; [email-masked]; [email-masked]; The IESG; "Mirja Kühlewind via Datatracker"
    Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)
    
    Hi, Randy and Alvaro:

    Thanks.  -- Enke

      
      
      4.  Operation

      

      
      4.  Operation

      

      

      

    
    -----Original Message-----
    From: Idr <[email-masked]> on behalf of Randy Bush <[email-masked]>
    Date: Tuesday, July 30, 2019 at 6:23 PM
    To: Alvaro Retana <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, "\"Mirja Kühlewind via Datatracker\"" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: [Idr]  Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

        randy

---

From: John Scudder <[email-masked]>
Date: Wed, 31 Jul 2019 17:03:28 +0000

(As a WG member)

On Jul 31, 2019, at 12:51 PM, Enke Chen (enkechen) <[email-masked]<mailto:[email-masked]>> wrote:

I agree — we have a formal definition of “BGP speaker” in RFC 4271:

   BGP speaker
      A router that implements BGP.

I don’t think we have a definition of “BGP listener” anywhere, nor is it in common use as far as I know. If I encountered the term without context or definition to tell me the meaning, I’d guess it to mean “a management station that passively consumes one or more BGP feeds but never advertises any routes”. That doesn’t appear to be the intended meaning here, so, better to switch to the well-defined term.

$0.02,

—John

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 31 Jul 2019 13:10:49 -0400

+1 to John’s comments.

Sue 

From: John Scudder [mailto:[email-masked]] 
Sent: Wednesday, July 31, 2019 1:03 PM
To: Enke Chen (enkechen)
Cc: Hares Susan; EXT - randy; Alvaro Retana; [email-masked]; [email-masked]; [email-masked]; The IESG; Mirja Kühlewind via Datatracker
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

(As a WG member)

On Jul 31, 2019, at 12:51 PM, Enke Chen (enkechen) <[email-masked]> wrote:

   BGP speaker

$0.02,

—John

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 31 Jul 2019 13:30:42 -0400

Alvaro:

Just to let you know that the text below:

“A peer which does not advertise this capability MUST NOT send BGP                                  

   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

was added due to comments on the IDR WG list from reviewers and operators.   

The peer is a “BGP peer” and it was debated on list that since this alters RFC4271 that this text was appropriate to indicate how BGP peers (which are not supporting Extended Messages” .     

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Wednesday, July 31, 2019 8:20 AM
To: Enke Chen (enkechen); Randy Bush
Cc: Mirja Kühlewind via Datatracker; [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

On July 30, 2019 at 9:53:36 PM, Enke Chen (enkechen) ([email-masked]) wrote:

Enke:

Hi!

I looked at the changes and they look good tome.  I think that generalizing to “speaker” does help.

Thanks!!

Alvaro.

*** bgp-large-msg-34.txt.orig  <http://airmail.calendar/2019-07-30%2018:24:32%20GMT-4> Tue Jul 30 18:24:32 2019 
--- bgp-large-msg-34.txt  <http://airmail.calendar/2019-07-30%2018:34:07%20GMT-4> Tue Jul 30 18:34:07 2019 
*************** Internet-Draft Extended Message sup 
*** 120,148 **** 
defined with Capability code 6 and Capability length 0. 

4. Operation 

4. Operation 

Extended Messages. See Section 8..

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 31 Jul 2019 13:05:56 -0700

Sue:

I think that this point was addressed in this thread [1], but I will send a
message to the WG to confirm.

It is good that we cross all our Ts Extended Message is an important change
to BGP.

Thanks!

Alvaro.

P.S.  BTW, we (me included) should probably not keep hijacking this thread
to address additional points. :-)

On July 31, 2019 at 1:31:11 PM, Susan Hares ([email-masked]) wrote: