Re: [Idr] I-D Action: draft-ietf-idr-dynamic-cap-16.txt

[Jeffrey Haas <[e-mail]>]

Enke, Srihari,

A few comments on draft-ietf-idr-dynamic-cap-16:

Section 2, Dynamic Capability:
:   The Dynamic Capability is a new BGP capability [RFC5492].  The
:   Capability Code for this capability is specified in the "IANA
:   Considerations" section of this document.  The Capability Value field
:   consists of a list of capability codes (one-octet for each) that
:   specify the capabilities that MAY be revised dynamically by the
:   remote speaker.

I've personally missed the vector of codes in each of my readings over the
years.  :-)

I'd suggest adding a packet diagram to call out this detail.

Section 3, Capability Message:

:    The Reserved bits should be set to zero by the sender and ignored by
:    the receiver.

Suggested changes:
The Reserved bits MUST be set to zero by the sender and SHOULD be ignored by
the receiver.

The usual logic here is the initial version needs to clearly use zeroes to
indicate it isn't doing something new with the bits.

Section 4, Operation:

:    A BGP speaker that is willing to receive the CAPABILITY message (for
:    one or more capability codes) from its peer SHOULD use the BGP
:    Capabilities Advertisement [RFC5492] to advertise the Dynamic
:    Capability for these capability codes.

Suggested changes:

s/SHOULD/MUST/

If the implementation has not received the Dyanmic Capability (capability),
the receipt of the Dynamic Capability Message would be a state machine
violation and result in a NOTIFICATION from an implementation that doesn't
support the feature.  

:    In order to avoid ambiguities in sending and processing UPDATE
:    messages, certain capability revisions may require close coordination
:    between the BGP speaker (the Initiator) that initiates the capability
:    revisions and another BGP speaker (the Receiver) that receives the
:    capability revisions.  The mechanism of acknowledgment defined in
:    this document SHALL be used for the revision of such a capability.
:    For the Initiator, the capability revision SHALL take effect (for the
:    purpose of sending updates) immediately after the capability revision
:    is sent, and the capability revision SHALL take effect (for the
:    purpose of receiving updates) immediately after an acknowledgment is
:    received from the Receiver.  For the Receiver, the capability
:    revision SHALL take effect (for the purpose of receiving updates)
:    immediately after the capability revision is received from the
:    Initiator, and the capability revision SHALL take effect (for the
:    purpose of sending updates) immediately after an acknowledgment is
:    sent.

I have concerns about this section.

It is possible for a BGP implementation to decide some set of capabilities
is locally unacceptable.  This happens as one of its cases for address
families.

The Dynamic Capabilities vector provides enough information to let the
implementation know that multi-protocol may be covered by the dynamic
capability message, but not what might happen if a given revision is
unacceptable.

Consider the case where a pair of implementations that have negotiated
dynamic capabilities has one of the pair requesting to add the EVPN address
family to a session.  The other of the pair does not support EVPN.

Using the text above, immediately after sending the capability revision, the
implementation would start sending EVPN Update messages.  Per RFC 4760,
Section 7, an implementation is permitted to simply ignore the unexpected
afi/safi.  However, it is also permitted to terminate the session.

It is not possible in the current Capability Message to determine if a given
revision is acceptable; only ack.

Section 5: Error Handling, see IANA issues below.

Section 6, Implementation Considerations:

I would recommend that the draft provide commentary on the currently
assigned BGP capabilities, perhaps in an Appendix.  See the registry, here:

https://www.iana.org/assignments/capability-codes/capability-codes.xhtml

When the chairs reviewed the list, the vast majority of features did not
seem amenable to dynamic capabilities.  The ones that make some level of
clear sense:

- Multi-protocol
- ORF (needs discussion)
- BGP Role?
- Graceful restart/LLGR
- FQDN

It seems potentially reasonable long term that part of the procedure for
requesting new capability codes from IANA would be a new column in the
capability registry noting whether the capability is expected to be
dynamically updated or not.

IANA issues:
[Note that these have been previously acknowledged and are listed here for
completeness.]

The request for BGP message type 6 should be moved to a suggestion.  The
request for a new NOTIFICATION code should be made here as well.

There is no registry created for the new subcodes.  This needs to go into
the IANA registration section.

The chairs would like ease allocation of these code points, especially if
there are implementations.  However, we need the implementation report
completed:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-dynamic-cap%20implementations

-- Jeff (for the chairs)


On Thu, Oct 21, 2021 at 11:43:31AM -0700, Enke Chen wrote:
> Hi, Folks:
> 
> Here is a brief summary of the BGP Dynamic Capability revisions:
> 
> Diff from versions 14 to 15:
>       Only template changes.
> 
> Diff from versions 15 to 16:
>      1) clarified a couple ambiguities related to "multi-instance" capabilities.
>      2) added a section on "Implementation Considerations".
> 
> Please let us know if you have comments on the draft.
> 
> Thanks.   -- Enke
> 
> On Thu, Oct 21, 2021 at 9:43 AM <[e-mail]> wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Inter-Domain Routing WG of the IETF.
> >
> >         Title           : Dynamic Capability for BGP-4
> >         Authors         : Enke Chen
> >                           Srihari R. Sangli
> >         Filename        : draft-ietf-idr-dynamic-cap-16.txt
> >         Pages           : 9
> >         Date            : 2021-10-21
> >
> > Abstract:
> >    This document defines a new BGP capability termed "Dynamic
> >    Capability", which would allow the dynamic update of capabilities
> >    over an established BGP session. This capability would facilitate
> >    non-disruptive capability changes by BGP speakers.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Ddynamic-2Dcap_&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CRGoVE4Y3OsDQszuvhiJG2zxPjCT-cuHKf-Td3gPH68&s=6MadxXZR9oT-f1JvgfYFdFuawPf7A8arUqqEegIH93k&e=
> >
> > There is also an htmlized version available at:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Didr-2Ddynamic-2Dcap-2D16&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CRGoVE4Y3OsDQszuvhiJG2zxPjCT-cuHKf-Td3gPH68&s=hZwgHzlm45qOw5csqGz_w2tF7stD0fOi9OpjLXeOutQ&e=
> >
> > A diff from the previous version is available at:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Didr-2Ddynamic-2Dcap-2D16&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CRGoVE4Y3OsDQszuvhiJG2zxPjCT-cuHKf-Td3gPH68&s=KtBgozwKJ2wkHUqR4I8pvEY3B68Voj-inm-EG7SG6tc&e=
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CRGoVE4Y3OsDQszuvhiJG2zxPjCT-cuHKf-Td3gPH68&s=3CqHXLRsB8_7kXJEB0bOHricoS2gg22U-oyu7iAIR84&e=
> >
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=CRGoVE4Y3OsDQszuvhiJG2zxPjCT-cuHKf-Td3gPH68&s=4cYQ81j94ouoA-st4zuVpYLThEtkXC8DskhOHk4Dgrc&e=
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr