Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Fri, 09 August 2019 20:38 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2F120118; Fri, 9 Aug 2019 13:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 RWfAzhok6l04; Fri, 9 Aug 2019 13:38:26 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 538DD12006B; Fri, 9 Aug 2019 13:38:26 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x79KQ2Om026915; Fri, 9 Aug 2019 13:38:24 -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=GSVV3Uur7Nf0DPT77HyZAuDW8fOLAEaaNcn1eK3BELo=; b=reACMWjrf8Zgj+J4JiDN/oYbtW1SP+0yy0JFKOHKGxRYNxKXKaaslh3voCFwD/bfegtR Q1IRitYsd6gvSgjvLTl0MeYiMs3bSOpg7Lkd+6c6AS9ndVNKQOix34hMgPurVrV/3JUk aemfU8rvVpyGDOlbFVXouWvzEkBVCFibkQICiKKG78Xz/3u5yV0WEqCrJNU26UgH5aza SKHJJE94DAu/y8b/TDWnC2xEnCTpoTQL2Vxu9LKGnRpzdTqyNzP4YxarnoTZWnlxOX97 VggF0ZmRRMz+4C71LdyjvoTyBVv+sXb+I1CPV00uyzzx3Hwj+2mwverJldYw2eYgGc3h xA==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2050.outbound.protection.outlook.com [104.47.32.50]) by mx0b-00273201.pphosted.com with ESMTP id 2u9fv3r0j0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Aug 2019 13:38:24 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UvVgeTXU+KEM85ci5wcxsf3FZPREXsXDA/S7imNqEHLbhb/KkcWxjsazyku7mw4Bp5LFawNPqLBurM0z+vkhhyWZ5bzLL3blavgfZB+u145OCRPd3nPxZMSlcECVaw1AeIVVzEYbLeBeXnaZn4WfR9olQuuXe/lDUSlV2s1NCto35XA+7vQAeL9QBwHgWceoaaOZL2x8rvqhyPT87NJTwP/mLImav+AkFEtIiBL76BuIsLPuNkXrrkjEyvAi9XfFEuj5867MCYHDmdYX7gPka3Ozfcz9EI/GoVi4H9iLGa51unxtv2VG+yZsCFy6k+lPKNguHaBc/lU/+xppN8Do/Q==
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=GSVV3Uur7Nf0DPT77HyZAuDW8fOLAEaaNcn1eK3BELo=; b=aw70MNEKQ+5Rn4E+AmvvXRfcQzD5KnX0zMwZedxKle+1h5XWHgqJIGv1MopM02B7xKc8BafT/MTQ1qpS2J2HmSIudwnQl/yZwHMUzI0zjOnD8Ea3sgBUPLDmUiLYCG9vA4WarEhZMIFD962KnIqxsFUDJrEv47Nh1lgq3OhIIcjtCLvR4v1V7+ddqdfE+ohwsIA0f70KLrSZCmDbTw5UVUHSUOnwxja8yrFdQv6tdGNIIeLpHp+VPVWPZDbmwao175xSdQHFqvcHViCOu6UW5Cyu2FIl8fM1636Nvv5jFXuQvh3N+sD0bgYPVnf0oSiRnwHPB1vXe3ySCCCEElk68w==
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
Received: from DM5PR05MB3548.namprd05.prod.outlook.com (10.174.242.153) by DM5PR05MB3227.namprd05.prod.outlook.com (10.173.225.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.8; Fri, 9 Aug 2019 20:38:20 +0000
Received: from DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::18d2:ef12:6593:9e2a]) by DM5PR05MB3548.namprd05.prod.outlook.com ([fe80::18d2:ef12:6593:9e2a%7]) with mapi id 15.20.2157.020; Fri, 9 Aug 2019 20:38:20 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, Robert Kebler <rkebler@juniper.net>, BESS <bess@ietf.org>
Thread-Topic: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
Thread-Index: AdSCOGobvyszpShjQe6cTmshOOxpcQGwJ0SwAPQjNQATOVJRcARi+wgABmfoLQAA1SowgA/sGpxgAW2C6QAAVn4TgA==
Content-Class:
Date: Fri, 9 Aug 2019 20:38:20 +0000
Message-ID: <DM5PR05MB35487E88B38742D6DEB5F666D4D60@DM5PR05MB3548.namprd05.prod.outlook.com>
References: <26502_1542873261_5BF660AD_26502_47_1_9E32478DFA9976438E7A22F69B08FF924B7752E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <BL0PR05MB5025A934922FDDC316AFD2E4D4AC0@BL0PR05MB5025.namprd05.prod.outlook.com> <CA+RyBmXcu3b9dObX=G9vyHNJtEuJ4wWqMtQXvxCNxgNOSCsmWw@mail.gmail.com> <CO2PR05MB24550CC9932A560B1DC7B19BD44B0@CO2PR05MB2455.namprd05.prod.outlook.com> <CA+RyBmV6oigz+ODY9C6QEqkDQY1X+x=yDpWqPoiODyyqVeTwHA@mail.gmail.com> <DM5PR05MB354829730C814ADE41F373CFD4310@DM5PR05MB3548.namprd05.prod.outlook.com> <CA+RyBmWNmdavTzoeGK+b1Tz-am6foNJ=1c5Kz7iKJ1gc7Lsvcg@mail.gmail.com> <DM5PR05MB35486A07622B1E28E781AE08D4D90@DM5PR05MB3548.namprd05.prod.outlook.com> <CA+RyBmXb-MrxwjQ9C5av+5XahJ1KjBb2QF=EHunMrCnidsqp=Q@mail.gmail.com>
In-Reply-To: <CA+RyBmXb-MrxwjQ9C5av+5XahJ1KjBb2QF=EHunMrCnidsqp=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=zzhang@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-08-09T20:38:16.4019525Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=f8c3a1b3-dd02-460f-841f-4051557ce81b; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1d9cf4b0-ebd6-4a06-4bc7-08d71d098430
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM5PR05MB3227;
x-ms-traffictypediagnostic: DM5PR05MB3227:
x-ms-exchange-purlcount: 2
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM5PR05MB3227F13560BDFEB4CFC6DE33D4D60@DM5PR05MB3227.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 01244308DF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(39830400003)(136003)(396003)(346002)(376002)(199004)(189003)(3846002)(476003)(6116002)(1411001)(52536014)(790700001)(5660300002)(229853002)(76116006)(14454004)(71200400001)(71190400001)(74316002)(86362001)(256004)(7736002)(66476007)(64756008)(66556008)(66446008)(66946007)(66066001)(6436002)(33656002)(55016002)(8676002)(54906003)(99286004)(6246003)(53936002)(54896002)(9686003)(316002)(6306002)(26005)(102836004)(2906002)(6506007)(6916009)(81166006)(81156014)(8936002)(11346002)(446003)(186003)(76176011)(25786009)(7696005)(4326008)(486006)(9326002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3227; H:DM5PR05MB3548.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4HK2Lu23xg4UBlkp8WjwO2BhM33a2arx9SozMnyXvCarG2QVOhWgIEVIuuxrDZpoe/fpfgNDfvHL6VAhFBfT4spOLZsq6fngb4KpL16ajV8xEhm27XebR7ZpaWCY0dgd6AhZroPVQx3pUsQ+iBQ1fe6D8JGioxiUV20XrnOmli7Pgz1/HHFDMRBAqcN3tQYjSREhgfELvMFUJ2JyGjIFgwNEySNJeOwIZWwxG4Nz9DfC994nvD7ws+kXj83xgoeFcv1q7gPdksSgaGD0sXMTiAYChnGPOYADkJfrqUOGk/hCeBV44+XmV2JBoz2ES3zbzh4DGAgd7QigNcPD7XGvdD0fBOOJN2pQeFJ7AFKEazoObCLKA83Faw0AX3zVIIBTfI3/J7dz2oRmqmtrFqBGOW/BiqIbI0d/b5KiZ3UMAJo=
Content-Type: multipart/alternative; boundary="_000_DM5PR05MB35487E88B38742D6DEB5F666D4D60DM5PR05MB3548namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d9cf4b0-ebd6-4a06-4bc7-08d71d098430
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 20:38:20.4194 (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: DPxMj9s0duIgRVwy4QUq+mSO09hs+oXmWaUE3j+WFVnMziwkG7iZKilkum8PohLbB+GSiYUNImtGtdPoSAvVVg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3227
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-09_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908090201
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/JT7_gytmVCVOzr52uPAWoiwS7EI>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2019 20:38:30 -0000

Hi Greg,

I've trimmed some text. Please see zzh3> below.

   Because all PEs may arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.
GIM3>> Got it, thx. Would s/may/could/ be acceptable to avoid questions about RFC2119-like language?
 Zzh2> I think it should be a MUST - otherwise you get duplicates when different PEs pick different upstream PEs.
GIM4>> I've tried s/may/MUST/ and it doesn't read right:
   Because all PEs MUST arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.
I'll do s/may/could/ to have this text:
   Because all PEs could arrive at a different
   conclusion regarding the state of the tunnel,
   procedures described in Section 9.1.1 of [RFC 6513] MUST be used
   when using inclusive tunnels.

Zzh3> My bad. I thought you were talking about must/MUST. "could" is fine since you were talking the "may".

Zzh2> I checked the surrounding text in this draft and section 5.1.3 in RFC6513. I believe section 3 of this document, before its subsection 3.1 should be re-written as following:
...
Zzh2> The reason is that for the candidate set is not ordered - it's just a set to select from (either based on IP address or hashing).
GIM4>> Many thanks, Jeffrey! Please check the working verion or diff and let me know if I've correctly applied the changes.

Zzh3> There is an extra "o":

   o  The first two options select the Upstream PE from a candidate PE
      set either based on IP address or a hashing algorithm.  When used
      together   with the optional procedure of considering the P-tunnel
      status as in   this document, a candidate upstream PE is included
      in the set if it either:

   o  <-- EXTRA

      A.  advertise a PMSI bound to a tunnel, where the specified tunnel
          is not known to be down or up



3.1.7.  Per PE-CE link BFD Discriminator
 ...
 Zzh2> Because you still want to track the tunnel state (in addition to pe-ce interface state), you would need at least two discriminators - one for the tunnel and one for the PE-CE link. However, the new "BGP- BFD attribute" defined in this spec only accommodates one discriminator (and my understanding is that you can't have more than one of the same attribute).
GIM4>> It is implied that the PE-CE link is monitored by p2p BFD session, most likely as described in RFC 5881 for single-hop BFD. That would not require bootstrapping.

Zzh3> I was saying that if you use "Per PE-CE link BFD Discriminator", then ...
Zzh2> The simplest solution is that just use the same discriminator (vs. per PE-CE link discriminator). With that, the ENTIRE section 3.1.7 (including its subsections) become the following:
GIM4>> I'm confused by "use the same Discriminator". The root advertises its Discriminator to the downstream PEs. The value is only locally unique for the root, not for any downstream PE. For a PE-CE link, if BFD is used, each PE must pick its locally unique value to use it as My Discriminator. CE uses that value in Your Discriminator field and thus the PE demultiplexes p2p sessions using its locally unique value in the Your Discriminator field. Note that p2mp BFD session among the root and the downstream PEs is such that PEs receives BFD control packets with the value of Your Discriminator field zeroed, and PEs use a different mechanism to demultiplex p2mp BFD sessions (as described in RFC 8562).

Zzh3> I meant that you don't use PE-CE link specific discriminator (e.g. value1 for the tunnel status, value2 for PE-CE link1 and value3 for PE-CE link2). Whether you track the PE-CE link status or not, you just include the discriminator that corresponds to the tunnel. I don't mean that all PEs use the same discriminator.

3.1.7 Tracking upstream PE-CE link status

   In case the PE-CE link on an upstream PE failed, even though the provider tunnel is still up,
   It is desired for the downstream PEs to switch to a backup upstream PE. To achieve that,
   If the upstream PE detects that its PE-CE link fails, it SHOULD set the bfd.LocalDiag of the
   p2mp BFD session to Concatenated Path Down and/or Reverse Concatenated Path Down,
   unless it switches to a new PE-CE link immediately (in that case the upstream PE will start tracking
   the status of the new PE-CE link).
   When a downstream PE receives that bfd.LocalDiag code, it treats as if the tunnel itself
   failed and tries to switch to a backup PE.
GIM4>> Would the downstream PE be switching to the backup Provider Tunnel, not to a backup PE? If yes, that option already listed in section 3.1.7.2

Zzh3> No.
Zzh3> Take one step back. When we don't track PE-CE link status on the ingress PE, we only care about the tunnel status. If it is down, we don't use the corresponding PE. There is no "backup tunnel". There is only a "backup upstream PE".
Zzh3> Now add the PE-CE link to the picture. Even if the tunnel remains up but if the PE-CE link is down, we don't use that upstream PE anymore. From the downstream PE's point of view, there is no difference whether it is the tunnel down or upstream PE-CE link down. It should not care.
Zzh3> That's why I say that the ENTIRE section of 3.1.7 should be replaced with my proposed text. No more 3.1.7.1 and 3.1.7.2.

Jeffrey


Juniper Business Use Only