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

[Robert Raszuk <[e-mail]>]

 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) <[e-mail]> 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:[e-mail]]
> *Sent:* Monday, July 6, 2020 5:43 PM
> *To:* Dongjie (Jimmy) <[e-mail]>
> *Cc:* Randy Bush <[e-mail]>; [e-mail]
> *Subject:* 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]>
> 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]] On Behalf Of
> > Dongjie (Jimmy)
> > Sent: Saturday, May 30, 2020 12:05 AM
> > To: Randy Bush <[e-mail]>
> > Cc: [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]]
> > > Sent: Thursday, May 28, 2020 12:46 AM
> > > To: Dongjie (Jimmy) <[e-mail]>
> > > Cc: [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]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Bush                    Expires November 26, 2020
> > > [Page 7]
> >
> > --
> > Bgp-autoconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bgp-autoconf
> --
> Bgp-autoconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bgp-autoconf
>
>