Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
Xiejingrong <xiejingrong@huawei.com> Wed, 23 January 2019 01:47 UTC
Return-Path: <xiejingrong@huawei.com>
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 CED7812D4E7; Tue, 22 Jan 2019 17:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 BIVIP64Re6fg; Tue, 22 Jan 2019 17:47:25 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A83F0130DC9; Tue, 22 Jan 2019 17:47:24 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6C7364E9F2E3E02EE2C5; Wed, 23 Jan 2019 01:47:22 +0000 (GMT)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 23 Jan 2019 01:47:19 +0000
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 23 Jan 2019 01:47:19 +0000
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Wed, 23 Jan 2019 01:47:19 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Wed, 23 Jan 2019 09:47:07 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "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: AdSpYQLeyyfnS0fsQTGEQTbsPNBRUAAghjzQAjV70XA=
Date: Wed, 23 Jan 2019 01:47:06 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB7FA1ED@nkgeml514-mbx.china.huawei.com>
References: <16253F7987E4F346823E305D08F9115AAB7E5219@nkgeml514-mbx.china.huawei.com> <CO2PR05MB24559F8A4B995C75BAF0BAB6D4850@CO2PR05MB2455.namprd05.prod.outlook.com>
In-Reply-To: <CO2PR05MB24559F8A4B995C75BAF0BAB6D4850@CO2PR05MB2455.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/plLeGsIGeeB5pR71cLdQup7TYoY>
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 01:47:27 -0000
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=A3B4H8kLvLDDH > 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=LDR59TMdGZLW > 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=
- [bess] Question regarding RFC6625 and this draft-… Xiejingrong
- Re: [bess] Question regarding RFC6625 and this dr… Jeffrey (Zhaohui) Zhang
- Re: [bess] Question regarding RFC6625 and this dr… Xiejingrong
- Re: [bess] Question regarding RFC6625 and this dr… Jeffrey (Zhaohui) Zhang
- Re: [bess] Question regarding RFC6625 and this dr… Xiejingrong
- Re: [bess] Question regarding RFC6625 and this dr… Jeffrey (Zhaohui) Zhang
- Re: [bess] Question regarding RFC6625 and this dr… Robert Raszuk
- Re: [bess] Question regarding RFC6625 and this dr… Jeffrey (Zhaohui) Zhang
- Re: [bess] Question regarding RFC6625 and this dr… Xiejingrong