Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017)

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Sat, 4 Feb 2017 00:44:03 +0000

At NIST we have two independent implementations of the BGPsec Protocol including 
the extended message capability as specified in “draft-ietf-idr-bgp-extended-messages-14”.

They are:
(1) QuaggaSRx, an extension to the Quagga router implementation
(2) BGPSEC-IO, a BGPsec traffic generator that allows generating multihop BGPsec updates.

QuaggaSRX:
==============
The implementation includes the following features in accordance with the draft:
1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended Capability: Yes
2. If BGP Extended Capability negotiated, then MUST receive and process message larger than 4096 bytes: Yes
3. If BGP Extended Capability not negotiated, then MUST NOT send message larger than 4096 bytes: Yes  
4. MAY accept EXTENDED MESSAGE from peer if not advertised BGP Extended Capability: Yes

BGPSEC-IO:
==========
The implementation includes the following features in accordance with the draft:
1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended Capability: Yes
2. If BGP Extended Capability negotiated, then MUST receive and process message larger than 4096 bytes: Yes
3. If BGP Extended Capability not negotiated, then MUST NOT send message larger than 4096 bytes: Yes  
4. MAY accept EXTENDED MESSAGE from peer if not advertised BGP Extended Capability: Yes

Thanks,
Oliver
-------------------------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Feb 2017 14:57:08 -0500

Oliver would you fill review the form at:  
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Please suggest changes to the way the implementation report is worded.  

Could you provide information on what happens if a peer: 
4a) SHOULD NOT Accept EXTENDED MESSAGE from peer if has not advertised BGP Extended Capability , and 
4b) It is not configured to the "MAY" that allows receiving the message Extended Messages 

Does it follows RFC4221 handling sending Bad Message Length Notification and resets session? 

Sue 

-----Original Message-----
From: Borchert, Oliver (Fed) [mailto:[email-masked]] 
Sent: Friday, February 3, 2017 7:44 PM
To: Susan Hares; John Scudder ([email-masked])
Cc: [email-masked]; [email-masked]
Subject: Re: Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017)

At NIST we have two independent implementations of the BGPsec Protocol including the extended message capability as specified in “draft-ietf-idr-bgp-extended-messages-14”.

They are:

QuaggaSRX:
==============
The implementation includes the following features in accordance with the draft:
1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended Capability: Yes 2. If BGP Extended Capability negotiated, then MUST receive and process message larger than 4096 bytes: Yes 3. If BGP Extended Capability not negotiated, then MUST NOT send message larger than 4096 bytes: Yes 4. MAY accept EXTENDED MESSAGE from peer if not advertised BGP Extended Capability: Yes

BGPSEC-IO:
==========
The implementation includes the following features in accordance with the draft:
1. Announce via BGP Capability advertisement (RFC5492) as BGP Extended Capability: Yes 2. If BGP Extended Capability negotiated, then MUST receive and process message larger than 4096 bytes: Yes 3. If BGP Extended Capability not negotiated, then MUST NOT send message larger than 4096 bytes: Yes 4. MAY accept EXTENDED MESSAGE from peer if not advertised BGP Extended Capability: Yes

Thanks,
Oliver

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 16 Feb 2017 00:40:34 +0000

Sue,
We updated our implementations and below find the updated implementation reports for QuaggaSRx and BGPSEC-IO:

Current Wiki summary:

1	Announce via BGP Capability advertisement (RFC5492) as BGP Extended Capability	Yes	Yes
2	If Extended Message Capability supported, Implementation MUST be able to:	-	-
2a	RECEIVE OPEN message larger than 4096 bytes (section 4, paragraph 2)	Yes	Yes
2b	RECEIVE A UPDATE message larger tan 4096 bytes	Yes	Yes
3	Applications putting data into BGP Extended messages MUST limit size of payload to handle max message sizes on pathway	Yes	Yes
4	Supports EXTENDED MESSAGE, but peer has not advertised BGP Extended Capability	-	-
4a	SHOULD NOT accept message	yes	yes
4b	MAY Accept EXTENDED MESSAGE (config/implementation knob)	Yes	Yes
5	Does not support EXTENDED Message (no support in code)		
5a	Does not send Extended Message capability		
5b	If receives Extended Message, follows RFC4221 handling and sends Bad message length Notification		

Updated Summary:

QuaggaSRx
==========
1) yes
2a) – Draft was updated – N/A
2b) yes
3) yes
4a) yes
4b) yes
5a) yes, can be configured
5b) yes, if configured to not support

BGPSEC-IO
=========
1) yes
2a) – Draft was updated – N/A
2b) yes
3) yes
4a) yes
4b) yes
5a) yes, can be configured
5b) yes, if configured to not support

Oliver

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Feb 2017 11:35:04 +0900

very cool.  thanks, oliver.

randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 16 Feb 2017 06:36:48 +0000

Hi Oliver, 

Thanks for the updates of the implementation report. I've updated the wiki page accordingly, including some editorial changes:

Please review and let me know if you have any comments.

Best regards,
Jie

> Sent: Thursday, February 16, 2017 8:41 AM
> To: Susan Hares <[email-masked]>; 'John Scudder' <[email-masked]>
> 3	Applications putting data into BGP Extended messages MUST limit size of
> payload to handle max message sizes on pathway	Yes	Yes

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 16 Feb 2017 13:39:47 +0000

Looks good to me,
Oliver

On 2/16/17, 1:36 AM, "Dongjie (Jimmy)" <[email-masked]> wrote:

    Hi Oliver, 

    
    
    Best regards,
    Jie

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Feb 2017 09:05:23 -0500

Oliver: 

Thank you for checking the updates.  Draft-ietf-idr-bgp-extended-messages has been sent to the IESG for publication. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Borchert, Oliver (Fed)
Sent: Thursday, February 16, 2017 8:40 AM
To: Dongjie (Jimmy); Susan Hares; 'John Scudder'
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Implementation call for draft-ietf-idr-bgp-extended-messages (1/24/2017 to 1/31/2017)

Looks good to me,
Oliver

    Hi Oliver, 

    
    
    Best regards,
    Jie
    
    > message length Notification

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