Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery

Sue,

> but the implementation selecting particular interface.

But this is precisely the crux of the perhaps subtle point.

Interesting/modern encapsulations are not (or do not need to be) expressed
as an interface. Neither logical nor physical.

Many thx,
R.

On Mon, Mar 21, 2022 at 12:35 AM Susan Hares <shares@ndzh.com> wrote:

> Robert:
>
>
>
> The L3DN only requires IPv4 or IPv6 native.  BGP, as a protocol only uses
> IPv4 or IPv6 native.
>
>
>
> I am comforted to hear that my use case is clearer.   I realize that most
> MPLS interfaces support IP routing/switching (for about 20 years).  Please
> note that it is not the protocol BGP that is enforcing the policy,  but the
> implementation selecting particular interface.    The encapsulation
> information is optional.
>
>
>
> If you wish to remove this option, it is a useful input to the authors.
>
>
>
> Thanks for your feedback.
>
>
>
> Sue
>
>
>
> *From:* Robert Raszuk [mailto:robert@raszuk.net]
> *Sent:* Sunday, March 20, 2022 7:21 PM
> *To:* Susan Hares
> *Cc:* Jeffrey Haas; idr@ietf. org;
> draft-minto-idr-bgp-autodiscovery@ietf.org; Minto Jeyananth
> *Subject:* Re: [Idr] BGP autoconfiguration -
> draft-minto-idr-bgp-autodiscovery
>
>
>
> Sue,
>
>
>
> What encapsulation happens to be used by BGP or for that matter any other
> protocol is (and should be) protocol agnostic.
>
>
>
> I hope we are not trying here to bind a TCP session to encapsulation X or
> Y irrespective of what routing (and given encap orchestration - LDP FEC
> binding or SR policy or something else) tells you to do. That would quickly
> get very very inconsistent and prone to many failures.
>
>
>
> Btw there is no such a thing as "MPLS interface". All MPLS interfaces I
> have seen do support IP routing/switching too. And honestly it may be much
> better if BGP keeps its transport limited to IPv4 and IPv6 native.
>
>
>
> Thx,
>
> Robert
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Mar 21, 2022 at 12:02 AM Susan Hares <shares@ndzh.com> wrote:
>
> Jeff:
>
> I'm really trying to answer your question - so if I do not understand your
> question.  I'll try again.
>
> The BGP transport sessions can have policy that requires the BGP hello to
> be
> exchanged across a L3 connection running on a particular MPLS interface.
> This policy ties down the TCP to a specific L3 connection on a specific
> L2.5
> connection.   This example, show the benefit for some overlay/underlay
> deployments.
>
> How does it impact the BGP FSM?   You will not get an TCP connection up due
> to machine policy (it is reject except for the l3 connection attached to
> specific MPLS interface).
>
> I really hope I've understood your question.
>
> Sue
>
>
> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
> Sent: Sunday, March 20, 2022 2:39 PM
> To: Susan Hares
> Cc: 'Minto Jeyananth'; idr@ietf.org;
> draft-minto-idr-bgp-autodiscovery@ietf.org
> Subject: Re: [Idr] BGP autoconfiguration -
> draft-minto-idr-bgp-autodiscovery
>
> Sue,
>
> I'm asking a very specific question.  Let me repeat:
>
> On Sun, Mar 20, 2022 at 02:33:56PM -0400, Susan Hares wrote:
> > You asked  L3DN is useful where besides the DC.
>
> No, I asked:
> > > It is still unclear what the "encapsulation" fields are used for with
> > > respect to BGP discovery.
>
> > I am looking for the same level of answer from the draft-minto-*.   Are
> they
> > planning to use this for WAN BGP auto-configuration.
>
> I'm not speaking for them.  Minto or Shiva can commment on their draft.
>
> > On the encapsulation,  as Randy has said AFI/SAFI.  Consider a data
> center
> > with multiple overlays (L2, mpls, L3) and AFI/SAFIs.  Suppose, you want
> to
> > use an MPLS interface for an L3 connections.  You might want to select a
> > specific set of labels for the underlay for L3DN.
>
> That's still not clear.
>
> How is this used to setup BGP's transport session during discovery?
> I.e. how does this impact BGP's TCP SYN and the rest of the session?
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>