Re: [Idr] BGP Classful Transport Planes

Kaliraj Vairavakkalai <kaliraj@juniper.net> Sat, 17 October 2020 23:47 UTC

Return-Path: <kaliraj@juniper.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 B22B53A1177 for <idr@ietfa.amsl.com>; Sat, 17 Oct 2020 16:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level:
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=T4nZuWL1; dkim=pass (1024-bit key) header.d=juniper.net header.b=NsT8rr0F
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 8maOhKXWi3Hy for <idr@ietfa.amsl.com>; Sat, 17 Oct 2020 16:47:17 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272DC3A115A for <idr@ietf.org>; Sat, 17 Oct 2020 16:47:17 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09HNlGGx007425; Sat, 17 Oct 2020 16:47:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=AHgHvCektAixhY08UXA3GyTim0NJO36ZonEuiRPDqpU=; b=T4nZuWL1F7oTcnS0ZIFzDNdGVMNcVS0IW+IMFwHj88Tb5+/2jqYtm2sFgkXhHsBrcWfS FMxEEdCGG8PLqnyec7YYv8nm/DRMDCkfOzTQezvnJc3m0dohbCajp4xPYZKR1/9d+np+ 9Qrf2IiEDBXGzjppl5tUFFOaJUOcihORhtQvCES83XPUTxHoWEgPSYnCa8EGIAOJlrMU QPTxQc74Au6LDi0fYBvdvy8R0/ldlr8Dfgh0beeVXG5YXBb+NfecnlwPMLSicHI1FNcH DMJr5ocYJK95e7gst+pvCkKLJRsZBDXYpeM0bG7oDktw0HiPY1dsr4ouKDrnKhewN4GL uA==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) by mx0a-00273201.pphosted.com with ESMTP id 347ymp8j1v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Oct 2020 16:47:16 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kk1QkWiblzeAZb9SFvtIUczFHnL0NQFd7m2RoX5aekkDy4m/Cc9L6NCkdFcOrZ3HgH60SW5QmFdjjkR4sG8RWsf6oyteNaQpk74froQcXZVQlVQqdsyDv3dqIWl8kO2colZ+usJG14nNupoqLh8fiOyktwQ2FohCDThg1XOFZus4nPlPVpYDJWwtXukZQltcYEJTRul7v1bOw/r9vbnQ2f891fvTjpJWzLVUmOmkem+jK9B5epG1t83AdSU4jcaSfXTRxZkw7r103ByHw1p9X1DzxbnHwQY1jZYPxYaeLeBvry/i6Q3qtrt/3qpW8K8yRa6CoPJU0/5noG5QwWoL/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AHgHvCektAixhY08UXA3GyTim0NJO36ZonEuiRPDqpU=; b=Tm1nugKIeJukJeh0oOGdWd8UcVMJveIe3Cbp5YcJXD1ykrnB/QCWkZ2DcOM6MKtcH95Dystwx6wi8ubXJDxnazRUXqKXL/aiMFp7iLMvqnIwE490u9AsMqWVYNO4gOzO0guwIeE9ZKOf++np52f6EYpTcVHQaJx/fMhjGrBpX9YyR3U1/yZfbaJm5UwH0URD/XJa8q9U2cLeBtB89F2hQYia0TPr9kCvWqG8vOfYNVWJPQBsvHc7gccP+8TUoTXyuOOj34tiPl/dDPORhJKDERPMz8UvkGxcp7rPsx+oNX5DmWXcv4Zz8Ru41GpzneAmtwCryC2+ZkCIa6o7z76K3g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AHgHvCektAixhY08UXA3GyTim0NJO36ZonEuiRPDqpU=; b=NsT8rr0FDmx7i2O3eTNgPnhwsgVxV5L6kMDYpR3+/kOpFh1N7emD+cV/6gmsniD/XQ2kHubcZ06C6WwV/4Zm6zi+StnIqtwvrpJRY8Q/+gxBdtTBuA+GLK4i/P/Je05gn76bjX/RQkBYE/7rdDyNnClvHGQ/+HX2Wz2HR/sKZzU=
Received: from BY5PR05MB7075.namprd05.prod.outlook.com (2603:10b6:a03:1bd::32) by BYAPR05MB6357.namprd05.prod.outlook.com (2603:10b6:a03:f1::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Sat, 17 Oct 2020 23:47:12 +0000
Received: from BY5PR05MB7075.namprd05.prod.outlook.com ([fe80::f944:d24a:1401:410f]) by BY5PR05MB7075.namprd05.prod.outlook.com ([fe80::f944:d24a:1401:410f%7]) with mapi id 15.20.3499.015; Sat, 17 Oct 2020 23:47:12 +0000
From: Kaliraj Vairavakkalai <kaliraj@juniper.net>
To: Robert Raszuk <robert@raszuk.net>, Natrajan Venkataraman <natv@juniper.net>, Balaji Rajagopalan <balajir@juniper.net>
CC: "idr@ietf. org" <idr@ietf.org>, Shraddha Hegde <shraddha@juniper.net>
Thread-Topic: BGP Classful Transport Planes
Thread-Index: AQHWpJpxW14vpdCoWEu7NQcRLbFx66mcARyA
Date: Sat, 17 Oct 2020 23:47:12 +0000
Message-ID: <59A888A2-682A-4A36-B80A-CC46DB02D1EA@juniper.net>
References: <CAOj+MMEdijdGVMKS3Qf-nabj0gZk+rrf7ygZ1H+6AyvxdP7xuA@mail.gmail.com>
In-Reply-To: <CAOj+MMEdijdGVMKS3Qf-nabj0gZk+rrf7ygZ1H+6AyvxdP7xuA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=73ed2be0-bd12-47a7-8dbf-dd6a4e3fbe89; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-17T23:02:29Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.242.15]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0cd6f5f5-18b2-4ab9-3928-08d872f6f858
x-ms-traffictypediagnostic: BYAPR05MB6357:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR05MB6357AB26B9F6A20C773041A3A2000@BYAPR05MB6357.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6/9HxHwMbBu4G81xt3iU2prgWXxYM+Trfpv7UGEYVUxw/1AlzVcbgprGJ8OXqnPNgDMj4edzacXbt63QlQpEpVdVB947Nt2VdLzEw6OpkKLMjBE+XLYrOR6ix8Q0L5HPox+PdOAQC/3Hy3pwqJLQ2ueWlcsrg2eLuNRqXWMA2WtJWsqtMT425AHwUO+cqXRS5ERYN3T7ES73iUMIGOj+94/1ubsPx87qn0Pgajr3MB82K78cX6l6iX2CKDLZg4pZSYKVAq0M6xHF0DXI9Oa9YDguijeUiIzj+UdYPdoT0f/vp9k8x99kTgZV5/+SDSL1aURQzx6ZEm8YcuqeFv5L9otle4Er7kPjNp5uFsK6N+QH5lm+T7GKmDxfnOxs6vxKGIAuBTt3iukDv9ZXX9pSIA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR05MB7075.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(346002)(366004)(376002)(396003)(6512007)(8676002)(4326008)(316002)(66556008)(64756008)(91956017)(107886003)(86362001)(6506007)(66476007)(166002)(2616005)(76116006)(66446008)(66946007)(5660300002)(36756003)(71200400001)(6636002)(6486002)(3480700007)(2906002)(8936002)(33656002)(53546011)(186003)(966005)(110136005)(83380400001)(478600001)(54906003)(26005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: dHYFIGOrbnqoqrDQb+IEJ1rAqpwEZcX54mNycj1gej3zmoDeg4GmYLpXWVI7uEAwi1JOcc2n0UaSRf+P1GnRIXuJPNi/IJxNmIzRNt4OfTyVGYalE2qNKZ/dXytrn+NDLhnOZq3gyv9IsymULqBHL+4S+ONEG3eRPnYsTrnpGmsEBNyKwz7lGsTgNjLyIEBYuHdcqlw2la/GjJPeD3ar2B82RY/5gjq1au0boUZt1Gvc9MTDK9r6kpgUdYUsA6ttNTFpCHwt3TzK8nWFUJ1FvrjX3J6uYnOkc2HLKhZp8QrmtoH5in/xwkozCP4RJButKSDztrdCeoG8AWnrIzxHWdatj4P5rA24PecyJBEeVhDQRJjWPWSXhEPyzFPSxL3Q1JYRO/IN42SNDODFzrDtKCRMwNxcyHGo41nW1yRZqnNz3hYQbxxM0ES1L1KbITlKEAmu8Ts0MeEbRT1l8pKu4Kpxg+gm/8yo+sKRZ822iT54A5FO6OmknQmVnHwLiW2m4aGkT6bv+uP8bLeYMnj+e4mkjuJE8vNvJoP6VgjcjN80erod9CQrJ3ZRmGoObNa+fkk3Ebvj0tb3qkcY0MqBI6z+Goe3dQAZ/SBd2qBgzTaDVkfZ10CB8enjgFbpW3h1i0aIHN+QvYP30mzNALlamg==
Content-Type: multipart/alternative; boundary="_000_59A888A2682A4A36B80ACC46DB02D1EAjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR05MB7075.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0cd6f5f5-18b2-4ab9-3928-08d872f6f858
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2020 23:47:12.5878 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 48oFBBykI8banvHsP+7T8+xdUxQdoTd9bA7a6mIz4BtWtW0eUhOOEFuEyhhShuCjjTpoiCO5rh6C69gMIoEpNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6357
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-17_20:2020-10-16, 2020-10-17 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 clxscore=1011 lowpriorityscore=0 adultscore=0 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010170177
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GB_QZV53FVXjOFk4QixJrBe7VuM>
Subject: Re: [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 23:47:20 -0000

Hi Robert, thanks for the comments. Please see inline.

From: Robert Raszuk <robert@raszuk.net>
Date: Saturday, October 17, 2020 at 8:30 AM
To: Kaliraj Vairavakkalai <kaliraj@juniper.net>et>, Natrajan Venkataraman <natv@juniper.net>et>, Balaji Rajagopalan <balajir@juniper.net>
Cc: "idr@ietf. org" <idr@ietf.org>
Subject: BGP Classful Transport Planes

[External Email. Be cautious of content]

Hi,

I have read https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01__;!!NEt6yMaO-gk!Xg6xfSibwETZhsptdOJv2QL0vVF8WVkztqeHhepYnVCyfQQAMILyPEH9JnXnhQDO$>
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<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-intarea-tunnels-10__;!!NEt6yMaO-gk!Xg6xfSibwETZhsptdOJv2QL0vVF8WVkztqeHhepYnVCyfQQAMILyPEH9Jl8x4R7Q$>

Q: Do we really need more signalling extensions instead of working with existing protocols to accommodate new applications ?

This is not an extension parallel to TEA. The above para means to say, when BGP speaker does nexthop-self on a advertised transport-route, the details of the intra-domain tunnel used in the advertising-domain is hidden from the BGP-speaker in the other domain receiving the route. Because it sees as nexthop only the advertising BGP-speaker.

Such nexthop-self happens in

  *   option-B VPNs, at the Service-ASBRs  (BGP-L3VPN families)
  *   option-C VPNs, at the Transport-ASBRs or BGP ABRs (BGP-LU and BGP-CT are examples of this)

So this act of doing nexthop-self demarcate the boundary between two domains. That boundary either link on an inter-AS link, or an ABR.

May be I should clarify the statement to use “transport-route” instead of tunnel-route. Will that make it clear?

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.

It will work. There are two cases here:

  *   intra-AS non-MPLS-tunnel.



As explained above, details of what type of intra-AS tunnel is used is confined to the tunnel boundary nodes. And we can encapsulate MPLS-traffic on other type of tunnels. So this will work.



  *   Inter-AS non-MPLS data-plane.



Yes, in this document we take the case of inter-AS link running MPLS data-plane. Because that is the most prevalent deployment today. But we have put thought into how the mechanisms prescribed in this document can work with non-MPLS data-planes also. But they are out of scope of this document.



In brief, instead of doing MPLS label-swap on the inter-AS link, we can do plain IPv6 forwarding. We may have a separate document in future, that will explain how mechanisms in this document adapt to SRv6 data-plane.




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.

   Supporting inter-AS MPLS data-plane has the following advantages:

  *   Uses and builds on top of deployment experience that we have gained thru the years.
  *   Preserves returns on investment made in existing deployments. i.e. Brown-field networks.
  *   Scales better. Because MPLS allows us to do build network hierarchies with nexthop chaining and label-stacks.

   But yes, if a green-field network decides to use IPv6 end-to-end, there are two ways it can be done:

  *   Use IPv6 for control-plane, and MPLS in the data-plane.
  *   Use IPv6 in the data-plane as-well. Even in this case, association of IPv6-tunnel endpoints with appropriate transport-class will be required. Which can be achieved with BGP-CT.

In summary, mechanisms described in BGP-CT are agnostic to

  *   What type of tunneling technology is used in the intra-AS transport-layer
  *   And what type of data-plane is used on the inter-AS links. Though the draft uses MPLS.

I will clarify the same in this draft. That, this draft uses MPLS as the defacto inter-AS data-plane, but the mechanisms will work with non-MPLS data-planes also. Future documents will specify details on how.

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.

Please note, BGP-Flowspec routes can be colored appropriately to achieve what you describe here. Flowspec becomes just another service-family that can resolve over transport-classes created by BGP-CT.

So, you could have an inet-unicast service-route advertised for the ‘cluster of compute servers’ with desired color mapping-community.

And further, inet-flowspec route with the 5-tuple can be advertised, with redirect-to-ip nexthop and color mapping community. Such that any flow mathing this flowspec route is redirected using the transport-class, that the color mapping community maps to.

Does that address this comment?

If yes, I can add some text to the draft describing the flowspec use-case.

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 ?

Sure. We will add text to the draft describing this. in brief,

At the Transport BNs:

  *   It will have BGP-CT route for remote-PE/32 in gold transport-RIB.
  *   This BGP-CT route will be marked un-usable, if there is no routes in the gold transport-RIB matching remote-PE/32
  *   It Will create mpls swap-routes when readvertising the BGP-CT route.

At the Ingress SN:

  *   It will have the BGP-CT route for remote-PE/32 route in gold transport-RIB, when gold-connectivity exists end to end.
  *   Service-routes carrying gold mapping-community will resolve using this gold transport-RIB route.

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 ?

Yes. The BGP-CT routes for a gold transport-class will fail resolving it’s nexthop if no gold tunnels exist. So, BGP-CT will not advertise it further. This is similar to the rules followed by any BGP-family regarding nexthop resolution.

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 ?

BGP-CT will depend on the individual intra-domain transport-tunneling technologies to monitor such metrics, and classify whether ‘gold reachabilty’ exists to the nexthop in question. BGP-CT provides a way to collect such information procured from various intra-domain tunnels, and stich it across multiple domains and give an end to end picture to the service routes. How exactly such parameters are monitored will be left to the purview of the individual tunneling technologies.

e.g. RSVP or SRTE can monitor such parameters at nodes along the path, and give feedback to the RSVP/SRTE ingress node, which either adjusts the ingress route in gold transport-RIB, or takes down the gold transport-route. Which will trigger appropriate response in the BGP-CT layer.

5.

> baby carrier

Nice !

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

Thanks! :)

Once we reach consensus on the various points discussed in this thread, we will update the draft.

Balaji, Natz, Shradha, please add if anything.

Thanks,
Kaliraj




Juniper Business Use Only