[Idr] BGP Classful Transport Planes
Robert Raszuk <robert@raszuk.net> Sat, 17 October 2020 15:30 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F354D3A0A9B for <idr@ietfa.amsl.com>; Sat, 17 Oct 2020 08:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd7yVpTRVLSf for <idr@ietfa.amsl.com>; Sat, 17 Oct 2020 08:30:24 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EEB3A0A97 for <idr@ietf.org>; Sat, 17 Oct 2020 08:30:23 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id u8so7745765ejg.1 for <idr@ietf.org>; Sat, 17 Oct 2020 08:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=cBfIyPWQMbAetucJV0pbTKDyjos1RY16xdJINNimzzI=; b=LGMiyPaRy3crrWaobHxzELwEMtyzeRFsWfarmjDEMsb0ij4PNx2fvOV9XQhiJ4wIiW SLSy7F3zZcGUESPmpvx4XgijGTRxtrC3+nj17RhIwPfoCKcGzh3VuDRgsG3Mi9XFGIaR oF+kPWUl9KG+V3FVBn4riIY/t1zFMxJBzlUDQOiXma19euKpgazMBXB/ugoL4uLo5N+7 B+BO1RxhQnDSzL48pRYdx54Pn9CIZM/lA0xWxwynebRr81Nri1T65bXhQSlpb6hjdIST Lp+cNAYxyU/5m+JR+P+6X9jsNYmIifIQMrOZ13Dwbjivsv916OF40qnwNj/P6lhziVTZ n+uQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=cBfIyPWQMbAetucJV0pbTKDyjos1RY16xdJINNimzzI=; b=KcoPeIarAU7S3afDws3vkmxTROU0bp9ReN+2D/y4qKVMwDI+Vc5Ib4xHcwepcaPNVo iPJTcWnvkzoz5SfKciYAqTJPR5cMO/x22bCCXVOnj26E6+C+E8B2YNAlla1Nt8EskPGc giv2Gx5KVYXushZKbs/f5djtO1mxpkv9BSIvdSc8zbolJaU66CQHGfBKNB2HcwrAEJYO /GwjoQqPhARTz6RH4y5I71m8SmRTqeWPlc4XO+oufhrJ7CalxhYFRDDd2ueP+73wJXmF HUc42xMJb25XLrMWGN6dDfa4BIm4xrOEPi4FVJNzLiXjzMMGQMMO1LR5m55ZEKLujrad 2oGw==
X-Gm-Message-State: AOAM533r8pbnY9ZBN2AJr99w7Sv/phnVLztordYZ/h0Gf+TGKPxMIY+G tYUev5Mos/OabDC4OqCtjPRFLM/x1apnXD6hVE4KOA==
X-Google-Smtp-Source: ABdhPJwm/OVwmEQmqQhT/CuFiioI5huvMSJeSw5TRb2GnwEmz2APwhwUNeJDf4x6RxUwBbmjbHCuJh5X04K4VyzKJSQ=
X-Received: by 2002:a17:906:5613:: with SMTP id f19mr8902217ejq.441.1602948622358; Sat, 17 Oct 2020 08:30:22 -0700 (PDT)
MIME-Version: 1.0
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 17 Oct 2020 17:30:11 +0200
Message-ID: <CAOj+MMEdijdGVMKS3Qf-nabj0gZk+rrf7ygZ1H+6AyvxdP7xuA@mail.gmail.com>
To: kaliraj@juniper.net, Natrajan Venkataraman <natv@juniper.net>, balajir@juniper.net
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ab1b205b1df8f2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hxu9IZXXD0CXhxZjKXVQuV_oasQ>
Subject: [Idr] BGP Classful Transport Planes
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Oct 2020 15:30:26 -0000
Hi, I have read https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01 and have few questions & observations. *1.* > A domain boundary is demarcated by a rewrite of BGP nexthop to 'self' while > readvertising tunnel routes in BGP. For advertising tunneling in BGP we already have a number of options. Starting from RFC5512 through draft-ietf-idr-tunnel-encaps-19 or https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10 Q: Do we really need more signalling extensions instead of working with existing protocols to accommodate new applications ? *2. * > The path uses MPLS label-switching when crossing domain boundary So if the network for any reason does not use MPLS in its data plane - what you are proposing here simply is not going to work. Just for clarity MPLS can be used for service plane demux while transport can still be pure IP. In contrast if you are carrying your services with SRv6 across your domains you actually have Seamless SR for free without yet another BGP SAFI and stack of tunnels. *3. * > Overlay routes carry sufficient indication of the Transport Classes they should be encapsulated over, > in form of BGP community called the "mapping community". My feedback here is that granularity to color routes and group routes into transport classes is not sufficient. If I have a cluster of compute servers which I advertise as a single address block I must have ability to define and disseminate flows in/out such cluster on a per application basis (ideally per flow 5 tuple). At min per dst port granularity would be must have. Just doing the dst based ip lookup and based on that placing the switching via proper color of inet.3 RIB will just not cut it. *4.* > Based on the mapping community, "route resolution" procedure on the ingress node selects from the > corresponding Transport Class an appropriate tunnel whose destination matches (LPM) the nexthop > of the overlay route. Assume I am using inter-as option C across my domians. So VPNv4 AF carries service routes with remote PEs next hops. Can you elaborate or better update the draft with a new section describing in detail the relation between transport next hops, border nodes and service next hop for a given service route across 3 domains ? For example what is not stated in the draft - if LPM match is sufficient here do you depend on BGP-CT to remove the advertisements to remote overlay tunnel endpoints when such endpoint fails ? Then how about not complete failure but partial service degradation (for example increased fabric drops) ? How do you intend to detect those and automate say "gold" class bypass around such BNs ? *5.* > baby carrier Nice ! Never used such term when describing CSC to customers :-) Cheers, Robert.
- [Idr] BGP Classful Transport Planes Robert Raszuk
- Re: [Idr] BGP Classful Transport Planes Kaliraj Vairavakkalai
- Re: [Idr] BGP Classful Transport Planes Robert Raszuk
- Re: [Idr] BGP Classful Transport Planes Kaliraj Vairavakkalai
- Re: [Idr] BGP Classful Transport Planes Gyan Mishra
- Re: [Idr] BGP Classful Transport Planes Robert Raszuk
- Re: [Idr] BGP Classful Transport Planes Kaliraj Vairavakkalai
- Re: [Idr] BGP Classful Transport Planes Kaliraj Vairavakkalai
- Re: [Idr] BGP Classful Transport Planes Gyan Mishra
- Re: [Idr] BGP Classful Transport Planes Kaliraj Vairavakkalai
- Re: [Idr] BGP Classful Transport Planes Gyan Mishra
- Re: [Idr] BGP Classful Transport Planes Shraddha Hegde