Re: [Idr] BGP autoconfiguration - draft-ymbk-idr-l3nd - Problem scope

[Jeffrey Haas <[e-mail]>]

Sue,

On Wed, Mar 02, 2022 at 06:05:03PM -0500, Susan Hares wrote:
> DT document 
> Problem-scope says:  "The current target environment is BGP used for the
> underlay protocol in data center networks."
> Simplicity: "The auto-discovery mechanism is designed to be simple. ... This

I'll give this one a light pass.  The TLS 1.1 spec is 80 pages of its own
text with multiple call-outs to other dependent specs for implementation.
That said, it's fairly easy to get implementations for embedded use in
applications these days.  

However, the operational and debugging complexity for TLS shouldn't be
discounted.  It's a tradeoff vs. security requirements.

> BGP  
> State Requirements:  "enough information to a BGP Speaker to initiate a
> connection in BGP protocols"
> Discovered session state: 
>  - IP address, Transport security parameters, GTSM, and BGP session Protocol
> State Version number. 
> BGP Protocol state 
> - AS numbers, BGP ID, Supported AFI/SAFIs 
> 
> Here the draft-ietf-idr-bgp-autconf-considerations-02.txt is unclear. 
> Does the BGP-Auto-discovery pass the AFI/SAFIs?  - 
> Does pass: LLDP  (Your draft) 
> Does not pass:   L3DL, L3DN, draft-minto-idr-bgp-autodiscovery 
> The ones who do not pass the AFI/SAFIs could easily add a TLV to do this. 

I believe Randy has covered this point.  They are intentionally withheld
from scope from the auto configuration protocol as being a source of
conflicting state.

Contrarily, AS number is part of the state discovered from BGP, yet
L3DL/L3ND have it. :-)

> L3ND 
> Scope:  Massive Data Center (MDC) 
> Simplicity:  Simplicity with
> Discovered state:  IP addresses, transport security, 
> Encapsulations + Encapsulation Interfaces, 

The L3ND authors have yet to make it clear why encapsulations are relevant
to BGP auto configuration.

Is the expectation that for a given interface L3ND will be advertising for
dozens, hundreds, thousands of BGP peering sessions?  The ULPC PDUs and
procedure seem to argue that for a given L3ND session that you may have one
of each AFI.

As Randy has himself emphasized multiple times in these efforts, 
RFC 1925 §2.(12) applies.


> L3NDversion, (see Open), DB-version (see serial number),  GTSM
> BGP protocol State: AS number, BGP ID, AFI/SAFI
> 
> Two exceptions: 
> 1)  BGP Protocol State Version number - If this means v4 for BGPv4, please
> revise the DT auto-configuration. 

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-autoconf-considerations-02
Section 2.3.1:

:   *  A version number representing when the BGP Session Protocol State
:      has last changed.  This can be used as a hint by an auto-discovery
:      client to determine when the state has been updated from a prior
:      version.  This can reduce repeated connections from an auto-
:      discovery client to the discovered BGP Speaker when information
:      has not changed.

> IMHO design choices for Transport are best: 
> reliable transport (lower timers) + ability to plug in good security. 

Transport considerations partly depend on the amount of state you're passing
around.  And, as noted elsewhere in these reviews, timers for carrying data
payload vary depending on network loss and framing issues.

A transport layer itself also has security considerations.

"good security" is a subjective point, as we're discussing.  It's perhaps
more precise to state that if you want the properties TLS gives you, you
need a session based transport.

> [Point-3] 
> There is also a pointer that the proposal may be intended for more general
> purposes than BGP Autoconfiguration:
> 
> :   L3ND might be found to be widely applicable to a range of routing and
> :   similar protocols which need Layer-3 neighbor discovery.
> 
> The proposal appears to be intended to be able to expanded to non-data
> center cases.
> [Sue - yes it can expand]

Given the intended scope of the work we've chartered is for BGP
autoconfiguration, it's reasonable that since the bulk of the procedure for
L3ND isn't for BGP sessions that it should be justified.

In the case of L3DL, BGP is along for the ride for applications LSVR
requires, so that makes sense.

> :   While L3ND is designed for the MDC, there are no inherent reasons it
> :   could not run on a WAN.  The authentication and authorization needed
> :   to run safely on a WAN need to be considered, and the appropriate
> :   level of security options chosen.
> 
> Such wider scoping was permitted by the autoconfiguration analysis but such
> work was left as out of scope for the DC case.
> [Sue - Not exactly.  See the security section 
> Section 3.6 "Different deployment models will have different and
> requirements"
> This section indicate this proposal could support an authentication model
> with more security. 
> It could also just run TCP]. 

The comment was targeted toward "WAN".

> [Point-4] 
[...]
> Given that the desired scoping context is point to point (typically a small
> number of addresses on a given link), it'd be helpful if the authors discuss
> scenarios wherein a large number of BGP sessions are expected to be
> discovered on such a link.
> [Sue:  The primary target is the massive Data Center (MDC) environment as
> the first sentence of the introduction indicates.  The revised text above
> shows correction from authors.  ]
> [Sue: The introduction provides you truth in advertising that it scales. ]

To repeat a question asked elsewhere: How many BGP peering sessions are you
expecting to do on a given link?

You can be as massive as you like.  But for the most part, the data center
discussions throughout this process have largely been in reference to
fabrics.  For most common fabric topologies, the individual per router radix
is not very large.  This puts us either into an unusually large number of
peering sessions per-interface, per-leaf or something that's not a fabric.

Understanding the desired scope of why "because MDC" applies to high scale
per-interface BGP peering is the key detail.

> - draft-acee-idr-lldp-peer-discovery operates over layer 2 embedded in the
>   LLDP protocol.  It is currently sessionless.  Discussion has suggested
>   that if, in the future, security or large packet considerations drive
>   requirements to need larger packets that LLDPv2 that is being currently
>   stanardized in IEEE can serve those purposes.  LLDPv2 provides a session
>   layer.
> - draft-minto-idr-bgp-autodiscovery uses layer 3 IP multicast exclusively
>   and does not have a session layer. 
> 
> [Sue: Jeff - based on the discussions, the next round of text L3DN will 
> Hellos with LDP style resolution (lowest IP = Client, Highest client=Server)
> 
> Design choice: 
> IMHO - a reliable transport and the security reduce errors and downtime. ] 

I believe these are non sequitir.

Please feel free to expand on why those properties have those impacts.

-- Jeff