Re: [Bgp-autoconf] 回复： Move forward with bgp autoconf requirements and design principle

["Dongjie (Jimmy)" <[e-mail]>]

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:[e-mail]]
Sent: Monday, July 6, 2020 6:01 PM
To: Bgp-autoconf <[e-mail]>; Dongjie (Jimmy) <[e-mail]>
Cc: Randy Bush <[e-mail]>; [e-mail]
Subject: 回复： [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

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

Xiaohu




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

> -----Original Message-----
> From: Bgp-autoconf [mailto:[e-mail]<mailto:bgp-autoconf-bounces@ietf..org>] On Behalf Of
> Dongjie (Jimmy)
> Sent: Saturday, May 30, 2020 12:05 AM
> To: Randy Bush <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> 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:[e-mail]<mailto:[e-mail]>]
> > Sent: Thursday, May 28, 2020 12:46 AM
> > To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>
> > 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: [e-mail]<mailto:[e-mail]>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Bush                    Expires November 26, 2020
> > [Page 7]
>
> --
> Bgp-autoconf mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/bgp-autoconf
--
Bgp-autoconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bgp-autoconf