Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 6 Jul 2020 08:28:50 +0000

Hi all, 

The IETF 108 meeting is approaching, as planned we need to provide a draft to WG to summarize the requirement and the design principles of BGP autoconf. Considering the limited time and based on what we have so far, I'd suggest to use the text proposed by Randy as the base to build that document. Please let me know your thoughts about this, Thanks. 

I've provided some comments & suggestions in my previous mail, and here I put some of them into the attached document (doc file is used to track the changes). I'd suggest the design team members to give this document a review and also provide your comments and suggestions. Thanks.

Best regards,
Jie

> -----Original Message-----
> From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of
> Dongjie (Jimmy)
> Sent: Saturday, May 30, 2020 12:05 AM
> To: Randy Bush <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
> and design principle
> 
> Hi Randy,
> 
> Thanks a lot for putting things together into a document. IMO it can be
> considered as the base of our deliverable to the WG, and other team
> members could raise comments to specific text to help improving it. I'd
> suggest everyone to read it and give your comments to the list (It is good to
> see Xiaohu already sent some comments)
> 
> And please see some initial comments from my side inline:
> 
> > -----Original Message-----
> > From: Randy Bush [mailto:[email-masked]]
> > Sent: Thursday, May 28, 2020 12:46 AM
> > To: Dongjie (Jimmy) <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf
> > requirements and design principle
> >
> > so, a small attempt to move forward again
> >
> > git be found at https://git.rg.net/randy/draft-bgp-discovery-layers
> >
> > randy
> >
> >
> >
> > Network Working Group
> R.
> > Bush
> > Internet-Draft                  Arrcus, Inc. & Internet Initiative Japan
> > Updates: 6811 (if approved)                                 May 25,
> > 2020
> > Intended status: Informational
> > Expires: November 26, 2020
> >
> >
> >                     Trade-offs in BGP Peer Discovery
> >                    draft-ymbk-bgp-discovery-layers-00
> >
> > Abstract
> >
> >    This draft is an exploration of the alternatives and trade-offs in
> >    BGP peer discovery at various layers in the stack.  It is based on
> >    discussions in the IDR WG BGP Discovery Design Team.  The current
> >    target environment is the datacenter; while keeping an eye not to
> >    preclude WAN deployment.  This document is not intended to become
> an
> >    RFC.
> >
> > Status of This Memo
> >
> >    This Internet-Draft is submitted in full conformance with the
> >    provisions of BCP 78 and BCP 79.
> >
> >    Internet-Drafts are working documents of the Internet Engineering
> >    Task Force (IETF).  Note that other groups may also distribute
> >    working documents as Internet-Drafts.  The list of current Internet-
> >    Drafts is at https://datatracker.ietf.org/drafts/current/.
> >
> >    Internet-Drafts are draft documents valid for a maximum of six months
> >    and may be updated, replaced, or obsoleted by other documents at
> any
> >    time.  It is inappropriate to use Internet-Drafts as reference
> >    material or to cite them other than as "work in progress."
> >
> >    This Internet-Draft will expire on November 26, 2020.
> >
> > Copyright Notice
> >
> >    Copyright (c) 2020 IETF Trust and the persons identified as the
> >    document authors.  All rights reserved.
> >
> >    This document is subject to BCP 78 and the IETF Trust's Legal
> >    Provisions Relating to IETF Documents
> >    (https://trustee.ietf.org/license-info) in effect on the date of
> >    publication of this document.  Please review these documents
> >    carefully, as they describe your rights and restrictions with respect
> >    to this document.  Code Components extracted from this document
> must
> >    include Simplified BSD License text as described in Section 4.e of
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 1]
> >
> 
> > Internet-Draft      Trade-offs in BGP Peer Discovery            May
> 2020
> >
> >
> >    the Trust Legal Provisions and are provided without warranty as
> >    described in the Simplified BSD License.
> >
> > 1.  Introduction
> >
> >    This draft is an exploration of the alternatives and trade-offs in
> >    BGP peer discovery at various layers in the stack.  It is based on
> >    discussions in the IDR WG BGP Discovery Design Team.  The current
> >    target environment is the datacenter; while keeping an eye not to
> >    preclude WAN deployment.  This document is not intended to become
> an
> >    RFC.
> >
> > 2.  Background
> >
> >    Previous design team discussions converged on a number of aspects of
> >    the problem.
> >
> > 2.1.  BGP is the Underlay
> >
> >    The assumed environment has BGP used as the underlay routing
> protocol
> >    in data center.
> >
> > 2.2.  Some Requirements
> >
> >    Some requirements have been agreed by the design team as follows:
> >
> >    o  Support IPv4 and IPv6 address families, but do not assume both are
> >       available.
> >    o  Support discovery of the peering addresses for the BGP session
> >       endpoints.
> >    o  Support using either a device's external interface or one of its
> >       loopback addresses for the BGP session endpoint.
> >    o  Support discovery of the peers' ASs.
> >    o  Agree on any BGP session authentication and parameters.
> >    o  Enable Layer 3 link liveness detection, such as BFD.
> >
> > 2.3.  Simplicity
> >
> >    The goal is to provide the minimal set of configuration parameters
> >    needed by BGP OPEN to successfully start a BGP peering.  The goal is
> >    specifically not to replace or conflict with data exchanged during
> >    BGP OPEN.  Multiple sources of truth are a recipe for complexity and
> >    hence painful errors.
> >
> >    Simplicity is key.  Features not absolutely needed will not be
> >    included in the design.
> >
> >
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 2]
> >
> 
> > Internet-Draft      Trade-offs in BGP Peer Discovery            May
> 2020
> >
> >
> > 3.  Assumptions
> >
> >    BGP OPEN will do the heavy lifting.
> >
> >    BGP discovery should not do anything that could be done by BGP
> OPEN.
> >    Two sources of the same data are a recipe for errors.
> >
> >    BGP peering will be selective; every BGP speaker may not want to peer
> >    with every other speaker.
> >
> >    Before BGP OPEN, there is discovery and there is choosing peers.
> >
> >    After discovery, it would be nice if another exchange was not needed
> >    before BGP OPEN.
> >
> > 4.  Needs of Discovery
> >
> >    In discovery, an aspiring BGP speaker needs to discover:
> >
> >    o  The set of possible peers,
> >    o  To start, discovery does not know the potential peers' layer three
> >       IP addresses.
> >    o  Each one's attributes, a deployment defined set, e.g.: leaf,
> >       spine, ice cream flavor, ...  These attributes are arbitrary and
> >       operator dependent.  No assumptions should be made, code
> points
> >       assigned,, etc.
> >    o  Each one's layer three peering address(es), and
> >    o  Other attributes required for BGP OPEN to succeed, e.g.
> >       authentication data.
> 
> The second bullet maybe more close to "assumptions"?
> 
> And perhaps the rest of list could merge with section 2.2?
> 
> >
> > 5.  Operator Configuration
> >
> >    Operator configuration should be able to decide at lest the
> >    following:
> >
> >    o  Select or otherwise filter which peers to actually try to BGP
> >       OPEN,
> >    o  What parameters to use, e.g.:
> >
> >       *  IP addressing: IPv4, IPv6, Loopback, or Direct
> >       *  Any special forwarding or routing needed for reaching the
> >          prospective peer, e.g., loopback,
> >       *  AS numbering, and
> >       *  BGP Authentication Options.
> >
> >
> >
> >
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 3]
> >
> 
> > Internet-Draft      Trade-offs in BGP Peer Discovery            May
> 2020
> >
> >
> > 6.  Success Criteria
> >
> >    What are the criteria for success and failure of the design
> >    decisions, and how do we measure them?
> 
> In my understanding this is about the design principle as mentioned in our
> slides on IDR virtual meeting. Here I put the summarized bullets here for
> reference, and we can have some discussion about each of them, and pick
> the common set agreed by the team.
> 
> o Independent from BGP session establishment
> 
> o Not affect or change BGP session establishment and routing exchange,
> other than the interactions for triggering the setup/removal of peer session
> based on discovery mechanism
> 
> o Generic for any link-layer protocol
> 
> o Make use of a currently implemented and deployed DC switch protocol to
> reduce the cost and complexity
> 
> o Make use of existing BGP protocol for automating the BGP session bring-up
> 
> o Widely applicable to a range of routing and similar protocols which need
> layer 3 discovery and characterization
> 
> o Length of the message size supported
> 
> >
> > 7.  Discovery at Layer Two
> >
> >    BGP Discovery at Layer-2 would entail finding potential peers on a
> >    LAN or on Point-to-Point links, discovering their Layer-3 attributes
> >    such as IP addresses, etc.
> >
> >    There are two available candidates for peer discovery at Layer-2,
> >    Link Layer Discovery Protocol, LLDP, and Layer 3 Discovery Protocol,
> >    L3DL [I-D.ietf-lsvr-l3dl].
> >
> > 7.1.  Link Layer Discovery Protocol (LLDP)
> >
> >    LLDP is a widely deployed protocol with implementations for most
> >    devices.  Unfortunately it does not currently reveal Layer-3 IP
> >    addresses.  There is an early LLDPv2 development to extend it in
> >    IEEE.
> >
> >    [I-D.acee-idr-lldp-peer-discovery] describes how to use the LLDP IETF
> >    Organizationally Specific TLV to augment the LLDP TLV set to
> >    transport BGP Config Sub-TLVs signaling
> >
> >    o  AFI,
> >    o  IP address (IPv4 or IPv6),
> >    o  Local ASs,
> >    o  Local BGP Identifier (AKA, BGP Router ID),
> >    o  Session Group-ID,
> >    o  BGP [Authentication] Session Capabilities, and
> >    o  Local Address (Next Hop).
> >
> >    Which of these are really necessary could be discussed.
> >
> > 7.2.  Layer-3 Discovery Protocol (L3DL)
> >
> >    L3DL [I-D.ietf-lsvr-l3dl] is an ongoing development in the IETF LSVR
> >    Working Group with the goals of discovering IP Layer-3 attributes of
> >    links, such as neighbor IP addressing, logical link IP encapsulation
> >    abilities, and link liveness which may then be disseminated using
> >    BGP-SPF and similar protocols.
> >
> >    L3DL Upper Layer Protocol Configuration, [I-D.ymbk-lsvr-l3dl-ulpc],
> >    details signaling the minimal set of parameters needed to start a BGP
> >    session with a discovered peer.  Details such as loopback peering are
> >    handled by attributes in the L3DL protocol itself.
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 4]
> >
> 
> > Internet-Draft      Trade-offs in BGP Peer Discovery            May
> 2020
> >
> >
> >    o  AS number,
> >    o  IP address, IPv4 or IPv6, and
> >    o  BGP Authentication.
> >
> >    L3DL and L3DL-ULPC have well-specified security mechanisms, see
> >    [I-D.ymbk-lsvr-l3dl-signing].
> >
> >    This is similar but not quite the sane as the needs of this IDR
> >    Design Team.  E.g., L3DL is designed to meet more complex needs.
> >    L3DL's predecessor, LSOE, [I-D.ymbk-lsvr-lsoe], was simpler and might
> >    be a better candidate for adaptation.  A week's work could customize
> >    the design for the IDR Design Team's needs.  But ...
> >
> >    Unlike LLDP, L3DL has only one implementation, and LSOE only one
> open
> >    source implementation, and neither is significantly deployed.
> 
> As you mentioned the implementation status of L3DL here, if possible
> perhaps the implementation of L3DL-ulpc and the LLDP extensions in
> previous section could also be provided, as it would be helpful if some
> experience could be learned and documented, which would guide the design
> in the next step.
> 
> >
> > 8.  Discovery at Layer Three
> >
> >    Discovery at Layer-3 can assume IP addressability, though the IP
> >    addresses of potential peers are not known a priori and need to be
> >    discovered before further negotiation.
> >
> >    The principal problem would appear to be discovery at Layer-3,
> >    because one neither knows whether to use IPv4 or IPv6.  This is
> >    exacerbated by the possibility of a potential peer not being on the
> >    local subnet, and hence broadcast and similar techniques may not be
> >    applicable.
> >
> >    If one can assume point-to-point links , then discovery might try
> >    IPv6 link-local or even IPv4 link-local.  Or maybe a link broadcast
> >    protocol.
> >
> >    For switched or bridged multi-point which is at least on the same
> >    subnet, VLAN, etc., broadcasts might be a viable approach.
> >
> >    There will be difficulty if one or both peers wish to use a loopback
> >    for peering.
> 
> Some information about another existing proposal
> draft-xu-neighbor-autodiscovery may also be included in this document.
> Perhaps Xiaohu could help with some text?
> 
> >
> > 9.  Discovery at Layer Seven
> >
> >    Peer discovery at Layer-7 requires application layer rendezvous
> >    mechanisms analogous to those used by LISP, [RFC6830] or the Bitcoin
> >    Protocol.
> >
> >    If the infrastructure is at all complex, e.g. multi-segment or worse,
> >    then it will need prior routing/forwarding knowledge in order to
> >    reach the rendezvous.  In a BGP centric deployment this could pose a
> >    chicken and egg problem.
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 5]
> >
> 
> > Internet-Draft      Trade-offs in BGP Peer Discovery            May
> 2020
> >
> >
> >    Rendezvous approaches may appeal to deployments which favor a
> central
> >    control framework.
> >
> >    On the other hand, those who favor distributed protocols will have
> >    the classic worries about fragility, redundancy, reliability, etc.
> 
> This section is interesting, although we didn't have discussion about this
> category before (based on my memory). Is this also related to the Sparse
> peering model in BGP-SPF? Or maybe I misunderstood your intention here.
> 
> Best regards,
> Jie
> 
> >
> > 10.  Security Considerations
> >
> >    None yet, but there will be many.
> >
> > 11.  Acknowledgments
> >
> >    The IDR BGP Discovery Design Team.
> >
> > 12.  IANA Considerations
> >
> >    None
> >
> > 13.  Normative References
> >
> >    [I-D.acee-idr-lldp-peer-discovery]
> >               Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu,
> >               "BGP Logical Link Discovery Protocol (LLDP) Peer
> >               Discovery", draft-acee-idr-lldp-peer-discovery-06 (work in
> >               progress), November 2019.
> >
> >    [I-D.ietf-lsvr-l3dl]
> >               Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery
> >               and Liveness", draft-ietf-lsvr-l3dl-04 (work in progress),
> >               May 2020.
> >
> >    [I-D.ymbk-lsvr-l3dl-signing]
> >               Bush, R. and R. Austein, "Layer 3 Discovery and Liveness
> >               Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in
> >               progress), May 2020.
> >
> >    [I-D.ymbk-lsvr-l3dl-ulpc]
> >               Bush, R. and K. Patel, "L3DL Upper Layer Protocol
> >               Configuration", draft-ymbk-lsvr-l3dl-ulpc-03 (work in
> >               progress), May 2020.
> >
> >    [I-D.ymbk-lsvr-lsoe]
> >               Bush, R., Austein, R., and K. Patel, "Link State Over
> >               Ethernet", draft-ymbk-lsvr-lsoe-03 (work in progress),
> >               November 2018.
> >
> >
> >
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 6]
> >
> 
> > Internet-Draft      Trade-offs in BGP Peer Discovery            May
> 2020
> >
> >
> >    [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
> >               Locator/ID Separation Protocol (LISP)", RFC 6830,
> >               DOI 10.17487/RFC6830, January 2013,
> >               <https://www.rfc-editor.org/info/rfc6830>.
> >
> > Appendix A.  Acknowledgements
> >
> >    The authors wish to thank .
> >
> > Author's Address
> >
> >    Randy Bush
> >    Arrcus, Inc. & Internet Initiative Japan
> >    5147 Crystal Springs
> >    Bainbridge Island, Washington  98110
> >    US
> >
> >    Email: [email-masked]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 7]
> 
> --
> Bgp-autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bgp-autoconf

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 6 Jul 2020 11:43:14 +0200

Team,

The draft in question specifically adds WAN auto conf.

Then the L3 peer auto discovery is just deferred to draft-ietf-lsvr-l3dl

However reading thorough draft-ietf-lsvr-l3dl it is clear that it is not
applicable to WAN. Just think common today BGP free core as example. It is
rather expected that core P nodes must not participate in edge (PE) auto
discovery.

I am personally fine to proceed with the current text for DC only, but for
WAN the solution of using new SAFI on the RRs just for configuration
dissemination IMO still is far more superior to the proposed solution.

If we want to pursue WAN as part of this draft I would propose to use
auto-discovery method as described in draft-raszuk-idr-bgp-auto-discovery
and explicitly add this as proposed solution for WAN auto configuration.

Many thx,
R.

On Mon, Jul 6, 2020 at 10:29 AM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi all,
>
> The IETF 108 meeting is approaching, as planned we need to provide a draft
> to WG to summarize the requirement and the design principles of BGP
> autoconf. Considering the limited time and based on what we have so far,
> I'd suggest to use the text proposed by Randy as the base to build that
> document. Please let me know your thoughts about this, Thanks.
>
> I've provided some comments & suggestions in my previous mail, and here I
> put some of them into the attached document (doc file is used to track the
> changes). I'd suggest the design team members to give this document a
> review and also provide your comments and suggestions. Thanks.
>
> Best regards,
> Jie
>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Mon, 06 Jul 2020 18:00:30 +0800

I fully agree with Robert that we’d better focus on DCN.

Xiaohu 

来自钉钉专属商务邮箱------------------------------------------------------------------
发件人：Robert Raszuk<[email-masked]>
日　期：2020年07月06日 17:43:14
收件人：Dongjie (Jimmy)<[email-masked]>
抄　送：Randy Bush<[email-masked]>; [email-masked]<[email-masked]>
主　题：Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

Team,

However reading thorough draft-ietf-lsvr-l3dl it is clear that it is not applicable to WAN. Just think common today BGP free core as example. It is rather expected that core P nodes must not participate in edge (PE) auto discovery. 

I am personally fine to proceed with the current text for DC only, but for WAN the solution of using new SAFI on the RRs just for configuration dissemination IMO still is far more superior to the proposed solution. 

If we want to pursue WAN as part of this draft I would propose to use auto-discovery method as described in draft-raszuk-idr-bgp-auto-discovery and explicitly add this as proposed solution for WAN auto configuration. 

Many thx,
R.

 The IETF 108 meeting is approaching, as planned we need to provide a draft to WG to summarize the requirement and the design principles of BGP autoconf. Considering the limited time and based on what we have so far, I'd suggest to use the text proposed by Randy as the base to build that document.. Please let me know your thoughts about this, Thanks. 

 Best regards,
 Jie

 > >    This Internet-Draft will expire on November 26, 2020..
 > >
 > > Copyright Notice
 > >
 > >    Two sources of the same data are a recipe for errors..
 > >
 > peering model in BGP-SPF? Or maybe I misunderstood your intention here..
 > 
 > Best regards,
 > Jie
 > 
 > >

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 6 Jul 2020 11:05:30 +0000

Hi Robert,

Thanks for your comment.

As stated in the design team report to IDR WG in IETF 107, the design team has agreed to work on the DC case first, while will also keep an eye on the difference in other cases such as WAN and IXP. Thus my personal opinion about this document is also to focus on DC only, perhaps the WAN and other cases can be left for next phase.

If this is also other team member’s understanding about the scope of this document, perhaps the description about WAN could be simply removed.

And I’d appreciate if some text contribution to section “Discovery at Layer Three” which is relevant to another BGP auto-discovery document of yours. Many thanks.

Best regards,
Jie

From: Robert Raszuk [mailto:[email-masked]]
Sent: Monday, July 6, 2020 5:43 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Randy Bush <[email-masked]>; [email-masked]
Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

Team,

Many thx,
R.

On Mon, Jul 6, 2020 at 10:29 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best regards,
Jie

> From: Bgp-autoconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Dongjie (Jimmy)
> To: Randy Bush <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> > From: Randy Bush [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
> > Cc: [email-masked]<mailto:[email-masked]>
> >    Email: [email-masked]<mailto:[email-masked]>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> [email-masked]<mailto:[email-masked]>
--
Bgp-autoconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bgp-autoconf

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 6 Jul 2020 11:17:34 +0000

Hi Xiaohu,

Thanks for providing your opinion on this. As mentioned in my reply to Robert, we have reached agreement to work on DC case first, thus IMO this scope could be clarified in the document.

Best regards,
Jie

From: 徐小虎(义先) [mailto:[email-masked]]
Sent: Monday, July 6, 2020 6:01 PM
To: Bgp-autoconf <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Cc: Randy Bush <[email-masked]>; [email-masked]
Subject: 回复： [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

Xiaohu

来自钉钉专属商务邮箱<(null)>
------------------------------------------------------------------
发件人：Robert Raszuk<[email-masked]<mailto:[email-masked]>>
日　期：2020年07月06日 17:43:14
收件人：Dongjie (Jimmy)<[email-masked]<mailto:[email-masked]>>
抄　送：Randy Bush<[email-masked]<mailto:[email-masked]>>; [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
主　题：Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle
Team,

Many thx,
R.

Best regards,
Jie

> From: Bgp-autoconf [mailto:[email-masked]<mailto:bgp-autoconf-bounces@ietf..org>] On Behalf Of
> Dongjie (Jimmy)

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 6 Jul 2020 14:29:12 +0200

Hi Jimmy,

Great that we agree on keeping the primary focus on DC.

With that do we have a common agreement that we need L3 level discovery for
establishing underlay routing protocol ? Seems very wired to me.

Likewise layer 7 ? Having rendezvous point for distributing configuration
data has been already proposed as L3 discovery in
draft-raszuk-idr-bgp-auto-discovery
which again was not even mentioned in section 5.3.

Last let me also observe that mentioned in section 5.2 of this
document draft-raszuk-idr-bgp-auto-session-setup-01
is not layer 3. It is layer 2 as BSE packets were defined to be using link
layer multicast.

I think the most constructive feedback is to go back and focus on DC layer
2 peer discovery only at this stage. draft-acee-idr-lldp-peer-discovery
could be a good candidate for that if folks think just talking BGP OPEN and
multicasting it on the links is to coarse of an idea :)

Best,
R.

On Mon, Jul 6, 2020 at 1:05 PM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Robert,
>
>
>
> Thanks for your comment.
>
>
>
> As stated in the design team report to IDR WG in IETF 107, the design team
> has agreed to work on the DC case first, while will also keep an eye on the
> difference in other cases such as WAN and IXP. Thus my personal opinion
> about this document is also to focus on DC only, perhaps the WAN and other
> cases can be left for next phase.
>
>
>
> If this is also other team member’s understanding about the scope of this
> document, perhaps the description about WAN could be simply removed.
>
>
>
> And I’d appreciate if some text contribution to section “Discovery at
> Layer Three” which is relevant to another BGP auto-discovery document of
> yours. Many thanks.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Monday, July 6, 2020 5:43 PM
> *To:* Dongjie (Jimmy) <[email-masked]>
> *Cc:* Randy Bush <[email-masked]>; [email-masked]
> *Subject:* Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
> and design principle
>
>
>
> Team,
>
>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 6 Jul 2020 15:13:35 +0000

Hi Robert,

In my understanding, the classification of L3 or L2 is based on which layer the discovery protocol runs over. For example, the LLDP approach is based on LLDP, which runs on layer 2, while both draft-xu-auto-discovery and draft-raszuk-auto-session-setup are extensions to BGP, which runs over IP/UDP, thus called L3 in the document. As discussed and analyzed, both L2 and L3 approaches could meet the minimal set of requirements, while they have differences in other aspects. So far I don’t recall we have agreement about whether the approach should be L2 or L3 protocol based, your preference of L2 based approach is noticed.

As for Layer 7 approach, I made one comment in the document, I’m not quite sure whether we need to mention it in this document, as the technologies described were not discussed in the design team. Any suggestion?

Best regards,
Jie

Sent: Monday, July 6, 2020 8:29 PM

 Hi Jimmy,

With that do we have a common agreement that we need L3 level discovery for establishing underlay routing protocol ? Seems very wired to me.

Likewise layer 7 ? Having rendezvous point for distributing configuration data has been already proposed as L3 discovery in draft-raszuk-idr-bgp-auto-discovery which again was not even mentioned in section 5.3.

Last let me also observe that mentioned in section 5.2 of this document draft-raszuk-idr-bgp-auto-session-setup-01 is not layer 3. It is layer 2 as BSE packets were defined to be using link layer multicast.

I think the most constructive feedback is to go back and focus on DC layer 2 peer discovery only at this stage. draft-acee-idr-lldp-peer-discovery could be a good candidate for that if folks think just talking BGP OPEN and multicasting it on the links is to coarse of an idea :)

Best,
R.

On Mon, Jul 6, 2020 at 1:05 PM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks for your comment.

Best regards,
Jie

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 6, 2020 5:43 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: Randy Bush <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

Team,

Many thx,
R.

Best regards,
Jie

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 6 Jul 2020 17:23:29 +0200

>   while both draft-xu-auto-discovery and draft-raszuk-auto-session-setup
are extensions to BGP, which runs over IP/UDP, thus called L3 in the
document.

That is not true - at least in respect to draft-raszuk-auto-session-setup

I am using multicast at the link layer so it is L2 based.

Hint: https://en.wikipedia.org/wiki/Multicast_address

Cheers,
R.

On Mon, Jul 6, 2020 at 5:13 PM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Robert,
>
>
>
> In my understanding, the classification of L3 or L2 is based on which
> layer the discovery protocol runs over. For example, the LLDP approach is
> based on LLDP, which runs on layer 2, while both draft-xu-auto-discovery
> and draft-raszuk-auto-session-setup are extensions to BGP, which runs over
> IP/UDP, thus called L3 in the document. As discussed and analyzed, both L2
> and L3 approaches could meet the minimal set of requirements, while they
> have differences in other aspects. So far I don’t recall we have agreement
> about whether the approach should be L2 or L3 protocol based, your
> preference of L2 based approach is noticed.
>
>
>
> As for Layer 7 approach, I made one comment in the document, I’m not quite
> sure whether we need to mention it in this document, as the technologies
> described were not discussed in the design team. Any suggestion?
>
>
>
> Best regards,
>
> Jie
>
>
>
> *Sent:* Monday, July 6, 2020 8:29 PM
> With that do we have a common agreement that we need L3 level discovery
> for establishing underlay routing protocol ? Seems very wired to me.
>
>
>
> data has been already proposed as L3 discovery in draft-raszuk-idr-bgp-auto-discovery
> Last let me also observe that mentioned in section 5.2 of this document draft-raszuk-idr-bgp-auto-session-setup-01

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jul 2020 08:53:29 -0700

> The draft in question specifically adds WAN auto conf.

that was certainly not the intent; and it's not really there in the
words.  on the other hand, if we should keep an eye on the WAN as we
design the LAN, we should be aware of choices which might unnecessarily
restriict ourselves next year.

> Then the L3 peer auto discovery is just deferred to

also not intended.  i did ask for your help stitching multicast in, and
you declined.  perhaps you have time now.

> applicable to WAN.

it is not applicable to many things :)

as i said at the beginning, i do not think l3dl is really a serious
candidate here.  otoh, we would be silly if we did not keep an eye to
see if there are lessons to be learned from it.

[ fwiw, i think the scalability added to lsoe to become l3dl was not
  worth the complexity.  but that is a discussion for another universe ]

randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 8 Jul 2020 15:47:41 +0000

Hi Randy and all,

It is good we agreed on the scope of this document is DC. Certainly in the design team we can analyze and discuss the difference between the design for DC and WAN, my understanding is the details about it does not belong to this document.

Coming back to the preparation of the draft deliverable, in addition to revising the existing text in the draft, my suggestion is to also add some brief description about each candidate solution regarding the functions, extensibility, etc., this may be similar to what was presented in the slides to the WG in last IETF meeting. I will work on some text and provide an update tomorrow. Any contribution to this is welcome.

As for the design principle (including which layer the protocol should be based on and the interaction with BGP), if we cannot reach agreement before the meeting, probably we could provide a summary of the considerations first, and ask for some feedbacks from the WG. Thoughts? 

Best regards,
Jie

> Sent: Monday, July 6, 2020 11:53 PM
> To: Robert Raszuk <[email-masked]>
> Cc: Dongjie (Jimmy) <[email-masked]>; [email-masked]
> that was certainly not the intent; and it's not really there in the words.  on
> the other hand, if we should keep an eye on the WAN as we design the LAN,
> we should be aware of choices which might unnecessarily restriict ourselves
> next year.
> 
> also not intended.  i did ask for your help stitching multicast in, and you
> declined.  perhaps you have time now.
> 
> > However reading thorough draft-ietf-lsvr-l3dl it is clear that it is
> > not applicable to WAN.
> 
> as i said at the beginning, i do not think l3dl is really a serious candidate here.
> otoh, we would be silly if we did not keep an eye to see if there are lessons to
> be learned from it.
>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 8 Jul 2020 11:02:11 -0700

Jie,

Sounds good, I don’t really see any convergence yet, so unbiased summary would be a great start

Cheers,
Jeff

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 09 Jul 2020 09:47:04 +0800

+1

------------------------------------------------------------------
From:Jeff Tantsura <[email-masked]>
Send Time:2020年7月9日(星期四) 02:02
To:Randy Bush <[email-masked]>; Robert Raszuk <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Cc:[email-masked] <[email-masked]>
Subject:Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

Jie,

Cheers, 
Jeff  

 Best regards,
 Jie

 -----Original Message-----
 From: Randy Bush [mailto:[email-masked]]
 Sent: Monday, July 6, 2020 11:53 PM
 To: Robert Raszuk <[email-masked]>
 Cc: Dongjie (Jimmy) <[email-masked]>; [email-masked]
 Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
 and design principle

 that was certainly not the intent; and it's not really there in the words.. on
 the other hand, if we should keep an eye on the WAN as we design the LAN,
 we should be aware of choices which might unnecessarily restriict ourselves
 next year.

 Then the L3 peer auto discovery is just deferred to
 draft-ietf-lsvr-l3dl

 randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 9 Jul 2020 16:44:42 +0000

Hi all,

As promised please find attached an updated version of the draft. I changed the draft title a little bit to better reflect the content and purpose. Thanks again to Randy for his effort on the initial version.

The design principles are listed in section 4 for further discussion. Some description about the candidate approaches draft-xu and draft-raszuk are added. The rest are some editorial changes.

Please review this document and provide your comments and suggestions, proposing text would be better. Note that the authorship and contributor of the design team document would be based on the contribution.

Although it may be quite challenging to get the draft ready before the submission cut-off, depending on the progress we made, perhaps we could have an -00 version first, then have it further revised before the meeting.

Many thanks,
Jie

From: 徐小虎(义先) [mailto:[email-masked]]
Sent: Thursday, July 9, 2020 9:47 AM
To: Bgp-autoconf <[email-masked]>; Randy Bush <[email-masked]>; Robert Raszuk <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

+1

------------------------------------------------------------------
From:Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Send Time:2020年7月9日(星期四) 02:02
To:Randy Bush <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc:[email-masked] <[email-masked]<mailto:[email-masked]>>
Subject:Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

Jie,

Cheers,
Jeff
On Jul 8, 2020, 8:47 AM -0700, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>, wrote:
Hi Randy and all,

Best regards,
Jie

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Monday, July 6, 2020 11:53 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
and design principle

randy