[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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


I have read
and have few questions & observations.


> A domain boundary is demarcated by a rewrite of BGP nexthop to 'self'
> 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

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.


> 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 ?


> baby carrier

Nice !

Never used such term when describing CSC to customers  :-)