Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Wed, 23 January 2019 16:32 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 9F33D130E9C; Wed, 23 Jan 2019 08:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.254
X-Spam-Level:
X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, 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 tCmZX6Os7HF8; Wed, 23 Jan 2019 08:32:23 -0800 (PST)
Received: from mx0b-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 A67DC130E97; Wed, 23 Jan 2019 08:32:23 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0NGHfM6029111; Wed, 23 Jan 2019 08:32:18 -0800
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 : content-transfer-encoding : mime-version; s=PPS1017; bh=DOrFpMrcFjImIEkyrZ8Slb8pFyBa2OTNI7yIKvYstS0=; b=1olvvbIyEfEM5weQJHZCPgw5HuapP4dQHwWPBQ2jS8zTBIz5poob4JWGMSVZ4qTUnY3x 0G1wdTwTlzDCNru/EltqHCPddFwbzryi+19BtwaCIyHvuu43JmTF+RVB519mWK+9BBU3 qBdxwNlYyK38VEhgoMRDZkTBkUQdDJgrFYGnlf162zDeJuWIaMyvm3VsfJXNuULBikri bq692RXmrln5SZ5J7m4JHeiurh5FaX92G+iIIvWEoN5kKFuCu7FHjFVj6ZSTseJ07jqV UCYQc9XyumlbIaTSa7nny/NgXqy0enwtmFT1WSu5F9yGsRAY0HwUQ/EJsdDOsPgGhD8t sg==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2057.outbound.protection.outlook.com [104.47.37.57]) by mx0a-00273201.pphosted.com with ESMTP id 2q6u4qr352-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Jan 2019 08:32:17 -0800
Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2424.namprd05.prod.outlook.com (10.166.95.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.14; Wed, 23 Jan 2019 16:32:15 +0000
Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::b852:f457:24e:fb7e]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::b852:f457:24e:fb7e%10]) with mapi id 15.20.1558.016; Wed, 23 Jan 2019 16:32:15 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Xiejingrong <xiejingrong@huawei.com>, "draft-ietf-bess-mvpn-expl-track@ietf.org" <draft-ietf-bess-mvpn-expl-track@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
Thread-Index: AdSpYQLeyyfnS0fsQTGEQTbsPNBRUAAghjzQAjV70XAAH5OuQA==
Date: Wed, 23 Jan 2019 16:32:15 +0000
Message-ID: <CO2PR05MB2455DFED5006162C8D906D79D4990@CO2PR05MB2455.namprd05.prod.outlook.com>
References: <16253F7987E4F346823E305D08F9115AAB7E5219@nkgeml514-mbx.china.huawei.com> <CO2PR05MB24559F8A4B995C75BAF0BAB6D4850@CO2PR05MB2455.namprd05.prod.outlook.com> <16253F7987E4F346823E305D08F9115AAB7FA1ED@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <16253F7987E4F346823E305D08F9115AAB7FA1ED@nkgeml514-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.600.7
dlp-reaction: no-action
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2424; 6:W/Un4IngIbAXUB147yEjqnqpGdgUNCP14bZRmpL9S1H9t1P+RN5+RTbAh7qoIeT09rKZwfQhDjuSBBJMO7ju+AwbG+4s05mmf1BngSgkockc2Bll0aqNeOYWesnqcSgXCb6L1+dNKbgZLgwi2VVNDx7UU7kXCUCodfQ3v5QVdIuV+SFiYvOmVNzYJcwMTnvmecThk0Awnyw6jmSPdK9feWY8jsqWxYGmDT2oVun1Nvon2N/YKzJ8R3DO4+hAehKg07nT4/yFTxD3yAS8p9NEfQr8gWwyrFY0Hz27Qwa3XXV7AqQWbT5TMPAgqH6I/60ev9RLC78r4DQDOniCUJ13wkcJ6Okf3aFBnnPSjiOPCNyM4e5BunxXPZhBBUgMu+teimlUf40FE4DmslR4Nv/LF5e8/IeSLYIE0uJ0hEa414q0iJvIMGNAm4uXKrP5PeBDBpmIUMzqXcNpluy8qc82WQ==; 5:ILJATEPPAtn5dDchNJ7XksqiB6ctRfq6B9FOZDXQ+DiBJSz5zrFfzMnEWVsEaxenHI1hlp8qhBvY0kpqBcnT+j07wsezw0QnPv6DMB0mtCLKKO6MFwtYkyQa0QO0Sz9J4xzo/dNlyBFrBUb1vdhwbS0WCEeR0Mwgawqr0DhqHpaRvadzgM44L0nsaYDPv0PU6S9tU9jWZhnXjWX1fNcdyA==; 7:L4rjq6zH/UCcRDSJ3BjFbcqBJ8B9tg6DHviwqdCeeggkgTcId9h7NXnLNyQFoqvYjDFwz6wCpNfjDgaA+oWMxT74MvzbsY4ZsfkUpUW6SI1VL5bUGxv5qJnTgGAjyD9UXsyr3x5Rkysd7VG6VB9AQA==
x-ms-office365-filtering-correlation-id: 12ba450f-18ce-4751-3635-08d6815055f6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:CO2PR05MB2424;
x-ms-traffictypediagnostic: CO2PR05MB2424:
x-microsoft-antispam-prvs: <CO2PR05MB2424D576CC71F1B0776E8F79D4990@CO2PR05MB2424.namprd05.prod.outlook.com>
x-forefront-prvs: 0926B0E013
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(39860400002)(366004)(376002)(346002)(13464003)(199004)(189003)(2906002)(4001150100001)(97736004)(14444005)(68736007)(66066001)(256004)(71200400001)(71190400001)(6306002)(76176011)(8936002)(7696005)(6436002)(8676002)(106356001)(229853002)(86362001)(81156014)(81166006)(55016002)(19627235002)(105586002)(316002)(66574012)(6246003)(53936002)(102836004)(2501003)(33656002)(6506007)(3846002)(110136005)(486006)(446003)(476003)(14454004)(6116002)(11346002)(966005)(53546011)(26005)(9686003)(99286004)(4326008)(25786009)(74316002)(7736002)(478600001)(305945005)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2424; H:CO2PR05MB2455.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: pITiM5XWp7C7n3/xWFcVKSirU3r0jYGhk4+xhEbcaj6ZLJ2rMmnI0W/3ZXd681u93bQchfCt01d0eajSrAmUIFBtxpLP1SKP/WXf5rFKXfdmZ0FfmcS/1SnxZy3Bjb/Hkf/MQ8Tk3OL/gqDsoOn/ZDLY7K3eOXzYV8sx4tj8ei6lDZIXo1HVAq+wXFspHWBwaI2t6iiFQySRs9LABcIBVFxJCP0k/1ugOLr8V/QwJqB22Qxxd4doNyrzAZB6m2fNnDD8fSDXf8nlw9iWFMnzbwAL1Ss1nDKsqnACTVai06K/9SVK074M5roWw+bgTxS9uqMn5Qf/6reXrjsXrj8G3pb7o33MxHeDnt1RqhZ5gR1h8VMB2Pn6VOiVVpt13DmA8uV7gXsHjyUYJqanaKuerCqL8WepIujKzJ3fiIqFjlk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 12ba450f-18ce-4751-3635-08d6815055f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2019 16:32:15.8288 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2424
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-23_09:, , 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-1810050000 definitions=main-1901230121
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/UqWUbrU25CZg7YuYI7VF5ffmG1Y>
Subject: Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
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: Wed, 23 Jan 2019 16:32:27 -0000

Hi Jingrong,

You're right that to avoid disruption and duplication a switchover delay is needed on the source PE and desired on the receiver PE, and that means the forwarding state needs to accommodate that.

However, the text is in RFC6625 is really/mainly about which tunnel to send/receive on in a steady state. That's not explicitly spelled out, but that's the intention per my understanding.

To be more accurate, the text is about which PMSI route to match. In theory a PMSI can be instantiated with one particular tunnel at one time and then switch to another tunnel. In that case the PMSI route is updated with a different PTA - the match to sending/receiving does not change yet the switchover delay referred to RFC6513 still applies.

Jeffrey

> -----Original Message-----
> From: Xiejingrong [mailto:xiejingrong@huawei.com]
> Sent: Tuesday, January 22, 2019 8:47 PM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-mvpn-expl-
> track@ietf.org
> Cc: bess@ietf.org
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Hi Jeffrey,
> 
> The sender PE need to work on (*,*) tunnel for a while (switch-over timer) and
> then switch to the (S,G) tunnel.
> 
> To quote RFC6513 section 7.1.1
>    The decision to bind a particular C-flow (designated as (C-S,C-G)) to
>    a particular P-tunnel, or to switch a particular C-flow to a
>    particular P-tunnel, is always made by the PE that is to transmit the
>    C-flow onto the P-tunnel.
> 
>    When a C-flow is switched from one P-tunnel to another, the purpose
>    of running a switch-over timer is to minimize packet loss without
>    introducing packet duplication.
> 
> Jingrong
> 
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
> Sent: Saturday, January 12, 2019 3:29 AM
> To: Xiejingrong <xiejingrong@huawei.com>; draft-ietf-bess-mvpn-expl-
> track@ietf.org
> Cc: bess@ietf.org
> Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
> Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Jingrong,
> 
> > It is determined by the sender site PE whether to steer the flow of (C-S, C-G)
> into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE should
> work correctly in any case.
> 
> Why would the sender PE send into (*, *) when there is a match for (S,G)?
> 
> Jeffrey
> 
> > -----Original Message-----
> > From: Xiejingrong [mailto:xiejingrong@huawei.com]
> > Sent: Thursday, January 10, 2019 11:10 PM
> > To: draft-ietf-bess-mvpn-expl-track@ietf.org
> > Cc: bess@ietf.org
> > Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action:
> > draft-ietf-bess-mvpn-expl-track-13.txt
> >
> > Hi,
> >
> > I have a question regarding RFC6625 and this draft, since this draft
> > is based on the RFC6625.
> >
> > In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data
> > Reception":
> > It defined the rules for Finding the matched S-PMSI A-D route for a
> > (C-S,C-G) state on a receiver site PE.
> > It seems to me that, the receiver site PE will respond only to the
> > *ONE* 'Match for Reception' S-PMSI A-D route, and setup the 'reception
> > state' only for the 'Matched' S-PMSI A-D route.
> > But it is not true for an inclusive-selective relation between S-PMSI
> > A-D (*,*) and S-PMSI A-D(S,G).
> > Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site
> > PE with a
> > (C-S,C-G) state should keep its join state on both the S-PMSI A-D
> > (*,*) and S- PMSI A-D(S,G), and setup the 'reception state' on both
> > the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel.
> > It is determined by the sender site PE whether to steer the flow of
> > (C-S, C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the
> > receiver site PE should work correctly in any case.
> >
> > My question:
> > Is the section 3.2.1 or RFC6625 wrong and should the 'Match for Reception'
> > include *one or many* S-PMSI A-D routes ?
> > Is it a problem that can affect this draft ?
> >
> > Thanks
> > Jingrong.
> >
> >
> > -----Original Message-----
> > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of internet-
> > drafts@ietf.org
> > Sent: Thursday, November 29, 2018 12:27 AM
> > To: i-d-announce@ietf.org
> > Cc: bess@ietf.org
> > Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
> >
> >         Title           : Explicit Tracking with Wild Card Routes in Multicast VPN
> >         Authors         : Andrew Dolganow
> >                           Jayant Kotalwar
> >                           Eric C. Rosen
> >                           Zhaohui Zhang
> > 	Filename        : draft-ietf-bess-mvpn-expl-track-13.txt
> > 	Pages           : 21
> > 	Date            : 2018-11-28
> >
> > Abstract:
> >    The Multicast VPN (MVPN) specifications provide procedures to allow a
> >    multicast ingress node to invoke "explicit tracking" for a multicast
> >    flow or set of flows, thus learning the egress nodes for that flow or
> >    set of flows.  However, the specifications are not completely clear
> >    about how the explicit tracking procedures work in certain scenarios.
> >    This document provides the necessary clarifications.  It also
> >    specifies a new, optimized explicit tracking procedure.  This new
> >    procedure allows an ingress node, by sending a single message, to
> >    request explicit tracking of each of a set of flows, where the set of
> >    flows is specified using a wildcard mechanism.  This document updates
> >    RFCs 6514, 6625, 7524, 7582, and 7900.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> > 2Dtrack_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=sbKFeLnAFP-
> > zpT69P-oClnR4lbitbdaZYjOsDepCjxo&e=
> >
> > There are also htmlized versions available at:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack-
> > 2D13&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=jlPz-
> > JVPIMj9q4cOW40qKs29IevDOPENoKn-oBQ3hK0&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> > 2Dtrack-2D13&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> >
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=A3B4H8kLvLDD
> H
> > AAYvRzveY09uFOBMr805O_uWxQmLRM&e=
> >
> > A diff from the previous version is available at:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> > 2Dtrack-2D13&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> >
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=TG7cPqa1m7LKi
> > Hevo2tvZm4uqipF4gU6MDp0Q_jfEpQ&e=
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern
> > et-
> > 2Ddrafts_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> >
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=LDR59TMdGZL
> W
> > rvkvp_MJXRgt1FSLYgwTCFbUnRffKgE&e=
> >
> > _______________________________________________
> > BESS mailing list
> > BESS@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> 3A__www.ietf.org_mailman_listinfo_bess&d=DwIFAg&c=HAkYuh63rsuhr6Sc
> > bfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> >
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU&s=BeypOtOdbV5x
> > DkM3hqVLXSveWQuyJ3MSOBTj1itnAqY&e=