Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update
Gunter Van De Velde <guntervandeveldecc@icloud.com> Mon, 26 October 2015 19:52 UTC
Return-Path: <guntervandeveldecc@icloud.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2691A0016 for <idr@ietfa.amsl.com>; Mon, 26 Oct 2015 12:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 os_feWmDXCiq for <idr@ietfa.amsl.com>; Mon, 26 Oct 2015 12:52:27 -0700 (PDT)
Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68F61A0015 for <idr@ietf.org>; Mon, 26 Oct 2015 12:52:26 -0700 (PDT)
Received: from [192.168.1.14] (159.91-131-109.adsl-dyn.isp.belgacom.be [109.131.91.159]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NWU00HISF77XV20@st13p11im-asmtp004.me.com> for idr@ietf.org; Mon, 26 Oct 2015 19:52:26 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-10-26_11:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=3 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510090000 definitions=main-1510260331
Content-type: multipart/alternative; boundary="Apple-Mail=_6542E540-F586-4E06-A66A-88C08BEA9BD3"
MIME-version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Gunter Van De Velde <guntervandeveldecc@icloud.com>
In-reply-to: <CA+b+ERmi_Hbd15VRdZz_bTQKPXVYjQmPDaQX2tFvAQrvyJpNdg@mail.gmail.com>
Date: Mon, 26 Oct 2015 20:52:21 +0100
Message-id: <75BE8144-D05B-4451-8208-A6297BEFADC2@icloud.com>
References: <009b01d10f2e$5cc28820$16479860$@ndzh.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5C638@nkgeml506-mbx.china.huawei.com> <4D6BC339-51BE-4F90-8858-9B81859858F0@alcatel-lucent.com> <CA+b+ERnU_sXmxzoEj9M=V+6_izqO2ZBTgS0QCJ0HF1h6qqXL-A@mail.gmail.com> <2F377A27-8529-416E-A3E8-BF2B3B6C9C50@alcatel-lucent.com> <CA+b+ERmnkajGwDSEDcPwMXj_QqCwAHydRgDe=Oyg+otpDTqY5A@mail.gmail.com> <1445881659836-b092aa37-9aa8905c-fae8f9db@icloud.com> <CA+b+ERm8PaptB-ZYPWT8M-hhUkABR_h2SQQXZQWVXCOHDVBsPA@mail.gmail.com> <42E7A0B2-5765-4F40-B908-216A95688690@icloud.com> <CA+b+ERmi_Hbd15VRdZz_bTQKPXVYjQmPDaQX2tFvAQrvyJpNdg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/Rj_0yYGP_FBNSuq_Oca1QLd_2og>
Cc: idr wg <idr@ietf.org>, Susan Hares <shares@ndzh.com>, "John G. Scudder" <jgs@bgp.nu>
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 26 Oct 2015 19:52:32 -0000
> On 26 Oct 2015, at 20:45, Robert Raszuk <robert@raszuk.net> wrote: > > > On PE1 the localised mapping of PATH_ID1 goes to Tunnel 1 > > On PE2 the localised mapping of PATH_ID1 goes to Tunnel 2 > > That would be highly confusing operationally. > It is an example to make a point… Its upto the operator of the PE how this is practically achieved. Its advisable for him to create something that makes sense :-) > > then the PATH_ID could seen as this VRF > > If so why not to use VRF which is already supported by all implementations? Having N ways to signal the same is never good idea. > Its not the same either… i hinted that this is an extreme use-case of PATH_IDs :-) G/ > Moreover you are not to worry about new mapping entity on all PEs of PATH_IDs to forwarding. > > But at least you got my point :) > > Cheers, > R. > > > > > On Mon, Oct 26, 2015 at 8:33 PM, Gunter Van De Velde <guntervandeveldecc@icloud.com <mailto:guntervandeveldecc@icloud.com>> wrote: > Ah… i think i see where the misunderstanding came from… > > Assume: > Flowspec rule 1 = [MATCH1] & [redirect_to_PATH_ID1] > > PATH_ID1 = redirect identifier to redirect_service_1 > > Redirect service has localised meaning: > On PE1 the localised mapping of PATH_ID1 goes to Tunnel 1 > On PE2 the localised mapping of PATH_ID1 goes to Tunnel 2 > Hence PATH_ID provides localised indirection, just like in the VRF case… > (the mapping of PATH_ID to the tunnel is done by a localised PATH_ID indexed table) > > i.e. look at an extreme use-case example: assume a VRF has only a single route (0/0) then the PATH_ID could > seen as this VRF…. it would result in exactly the same forwarding compared to using VRF redirect > or PATH_ID redirect in this extreme case… > > > G/ > > > > >> On 26 Oct 2015, at 20:10, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote: >> >> > I see no difference as with traditional flowspec where >> > redirect is to VRF or even IP address... Its same situation >> > there. >> >> I don't think it is same situation. >> >> Redirect to VRF provides local indirection. VRF can be the same on all PEs where you map redirected data to whatever you like. >> >> Redirect to IP also is very different as the IP address typically represents a single point (or anycast point) of processing device for all redirected flows from all PEs. >> >> The draft in the subject however as you have also explained targets to provide mapping to unique per PE PATH_IDs for the same flow. >> >> Perhaps you can illustrate on example how flowspec update coming from PE1 via RR can influence for a given NLRI matching traffic to take different PATH-IDs on PE2 and PE3. >> >> Cheers, >> r. >> >> >> >> >> On Mon, Oct 26, 2015 at 6:47 PM, Gunter Van De Velde <guntervandeveldecc@icloud.com <mailto:guntervandeveldecc@icloud.com>> wrote: >> There is miscommunication somewhere. >> >> Why do i wanna send another PATH_ID in a new NLRI? That does indeed do what you indicate. However that is not the intention. >> >> I see no difference as with traditional flowspec where redirect is to VRF or even IP address... Its same situation there. >> >> G/ >> >> >> >> Sent using CloudMagic Email <https://cloudmagic.com/k/d/mailapp?ct=pa&cv=7.4.10&pv=6.0&source=email_footer_2> >> On Mon, Oct 26, 2015 at 6:35 PM, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote: >> >> Gunter, >> >> Sorry but I am afraid this does not work :(. >> >> BGP uses notion of implicit withdraw for a given NLRI. >> >> So for particular flow NLRI I can advertise only single PATH_ID as subsequent NLRI with different PATH_ID will be treated as withdraw of the former. >> >> So if indeed as you said "..each PE the redirect tunnel will share the unique PATH_ID .." that effectively means that for a given flow NLRI I can advertise redirect service to only one PE pretty much killing p2mp advantage of BGP and what's worse blocking from advertising the same flow NLRI with any different set of actions. >> >> Best, >> R. >> >> >> >> >> On Mon, Oct 26, 2015 at 6:15 PM, VAN DE VELDE, Gunter (Gunter) <gunter.van_de_velde@alcatel-lucent.com <mailto:gunter.van_de_velde@alcatel-lucent.com>> wrote: >> Robert, >> >> Yeah, BGP is indeed p2mp relationship… This is important to keep in mind, and that it is exactly why PATH-ID makes sense. >> >> With 32-bit you have 2^32 and with 128-bit you have 2^128 unique identifiers. That is quite a lot and will serve redirect policies in most networks I would assume. >> >> In manual setup it is simple for a single PE: >> Preconfigure the PE with a tunnel and map it to a given unique PATH_ID >> This tunnel now exists, however it is not used >> Now the controller (i.e. vRR) sends a flow spec rule to identify the traffic using this tunnel and steers traffic into this tunnel >> When you have multiple PE’s using a single redirect service: >> Same setup as above, but on each PE the redirect tunnel will share the unique PATH_ID reflecting the redirect tunnel service >> (there is no relationship that the destination is the same… just the redirect service is the same) >> When you have 5000 of these Redirect services planned: >> Manual config will make you go crazy very soon >> The above can be 100% orchestrated or a mix of manual/orchestrated could be used >> >> The benefit of redirect-to-PATH_ID facilitates that network redirect service it decoupled from the tunnel creation/characteristics. hence the setup of a mp2p tunnel is beyond the scope the path_ID redirect draft if that happens to be the redirect service you had in mind. >> >> G/ >> >> >> From: <rraszuk@gmail.com <mailto:rraszuk@gmail.com>> on behalf of Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> >> Date: Monday 26 October 2015 at 17:41 >> To: Gunter Van de Velde <gunter.van_de_velde@alcatel-lucent.com <mailto:gunter.van_de_velde@alcatel-lucent.com>> >> Cc: Lizhenbin <lizhenbin@huawei.com <mailto:lizhenbin@huawei.com>>, Susan Hares <shares@ndzh.com <mailto:shares@ndzh.com>>, "idr@ietf.org <mailto:idr@ietf.org>" <idr@ietf.org <mailto:idr@ietf.org>>, "jgs@bgp.nu <mailto:jgs@bgp.nu>" <jgs@bgp.nu <mailto:jgs@bgp.nu>> >> Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update >> >> Hi Gunter, >> >> Let's observe that BGP signalling is p2mp. >> >> Now let's also notice that as you correctly state TE tunnels are rather custom crafted p2p entities. >> >> Then natural question comes to mind ... >> >> How good does it serve to signal identical PATH_ID to all head ends for a given flow while what you need to do is to map it rather uniquely in the network ? >> >> While in theory one could construct number of mp2p TE forwarding graphs each with identical PATH_ID on a per flow basis I bet in practice this was not the application you had in mind as its opex would be rather high as compared to real practical usefulness :) >> >> Side question ... How are you going to provision mp2p TE ? Are you going to dust-off some proposals for it from the past ? Example: https://tools.ietf.org/html/draft-yasukawa-mpls-mp2p-rsvpte-06 <https://tools.ietf.org/html/draft-yasukawa-mpls-mp2p-rsvpte-06> >> >> Or was perhaps your plan to provision number of p2p TE tunnels from PCE/Controller with the identical PATH_IDs ? >> >> Cheers, >> R. >> >> >> On Mon, Oct 26, 2015 at 5:26 PM, VAN DE VELDE, Gunter (Gunter) <gunter.van_de_velde@alcatel-lucent.com <mailto:gunter.van_de_velde@alcatel-lucent.com>> wrote: >> Hi Robin, >> >> Thanks for your note. >> >> A tunnel is not always going over shortest path. Some tunnels are TE tunnels and are deliberately not going over a shortest path. This is something that draft-rosen-idr-tunnel-encaps-00 will not help to signal because the tunnel-encap attribute indicates tunnel parameters used by the tail-end. >> >> If a redirect tunnel represents a particular redirect/steering service (better delay, less packet loss, non-SRLG, more BW, etc…) then it does become rather complex for BGP as signalling technology because a tunnel relationship is a unique between 'a headend' and ‘a tailed' device. It seems better to leave tunnel-setup to dedicated tunnel-setup mechanisms like PCEP, SR, etc…. >> >> The draft redirect-to-PATH_ID is providing the means to signal a flow-based redirect/steering service, and have each recipient router identify using local recursion for the PATH_IDs the corresponding tunnels/redirect-info. This allows for tunnel setup complexity to be taken away from BGP, while at the same time BGP is doing what it is very good at doing: "It signals a policy” in reliable fashion. >> >> Kind Regards, >> G/ >> >> >> >> From: Idr <idr-bounces@ietf.org <mailto:idr-bounces@ietf.org>> on behalf of Lizhenbin <lizhenbin@huawei.com <mailto:lizhenbin@huawei.com>> >> Date: Monday 26 October 2015 at 16:51 >> To: Susan Hares <shares@ndzh.com <mailto:shares@ndzh.com>>, "idr@ietf.org <mailto:idr@ietf.org>" <idr@ietf.org <mailto:idr@ietf.org>> >> Cc: "jgs@bgp.nu <mailto:jgs@bgp.nu>" <jgs@bgp.nu <mailto:jgs@bgp.nu>> >> Subject: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update >> >> Hi Gunter, >> >> Regarding your presentation, I have following comments: >> >> Do you mean draft-hao-idr-flowspec-redirect-tunnel is to signal tunnel setup info? draft-hao-idr-flowspec-redirect-tunnel is to steer traffic to the tunnel instead of signal tunnel setup. >> >> I am not sure if the reuse of draft-rosen-idr-tunnel-encaps-00 in the draft make you confused? We just hope to just reuses the attributes of to specify the tunnel type to help steering >> >> the traffic to tunnel. If this is not a good way, maybe we can define new attributes. >> >> >> >> >> >> Best Regards, >> >> Robin >> >> >> >> >> >> >> >> >> >> >> >> 发件人: Idr [mailto:idr-bounces@ietf.org <mailto:idr-bounces@ietf.org>] 代表 Susan Hares >> 发送时间: 2015年10月25日 22:07 >> 收件人: idr@ietf.org <mailto:idr@ietf.org> >> 抄送: jgs@bgp.nu <mailto:jgs@bgp.nu> >> 主题: [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update >> >> >> >> IDR WG members: >> >> >> >> Below is an updated agenda for the IDR interim on 10/26/2015. >> >> >> >> Sue >> >> >> >> ------------ >> >> IDR interim October 26, 2015 >> >> 10:00 - 11:30am >> >> >> >> 1. Chair's slides [10:00-10:05] >> >> >> >> 1. draft-litkowski-idr-flowspec-interfaceset-01.txt >> >> speaker: Stephane Litowski >> >> Time: 10:05-10:15 >> >> https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ <https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/> >> >> >> 2. draft-hao-idr-flowspec-redirect-tunnel-00 >> >> Speaker: Weiguo Hao >> >> Time: 10:15 - 10:25 >> >> http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ <http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/> >> >> >> >> >> 3. draft-vandevelde-idr-flowspec-path-redirect >> >> Speaker: Gunter Van De Velde >> >> Time: 10:25- 10:35 >> >> http://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/ <http://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/> >> >> >> >> >> 4. Draft Name: draft-hao-idr-flowspec-nvo3-02 >> >> Speaker: Weiguo Hao >> >> Duration: 10:35-10:40 >> >> http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ <http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/> >> >> >> >> >> 5. draft-liang-idr-bgp-flowspec-label-01.txt. >> >> Speaker: >> >> Duration: 10:40-10:45 >> >> http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ <http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/> >> >> >> 6. draft-liang-idr-bgp-flowspec-time >> >> presenter: Jianjie You >> >> time: 10:45-10:55 >> >> http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/ <http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/> >> >> >> 7. Draft Name: draft-li-idr-mpls-path-programming-02 >> >> Speaker: Zhenbin Li >> >> Duration: 10:55-11:05 >> >> http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/ <http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/> >> >> >> 7. Draft Name: draft-li-idr-flowspec-rpd-01 >> >> Speaker: Shunwan Zhuang >> >> Duration: 11:05 - 11:15 >> >> http://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ <http://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/> >> >> >> 8. Discussion of Flowspec drafts >> >> 11:15 - 11:30am >> >> >> >> Meeting Web-ex information >> >> Monday, October 26, 2015 >> >> 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs >> >> >> >> webex infor: >> >> https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f <https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f> >> >> >> Meeting number: 644 964 970 >> >> Meeting password: flow.in.nets >> >> >> >> >> >> Join by phone >> >> 1-877-668-4493 <tel:1-877-668-4493> Call-in toll free number (US/Canada) >> >> 1-650-479-3208 <tel:1-650-479-3208> Call-in toll number (US/Canada) >> >> Access code: 644 964 970 >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org <mailto:Idr@ietf.org> >> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr> >> >> >> >> > >
- [Idr] IDR interim (10/26/2015) 10:00am - 11:30am … Susan Hares
- Re: [Idr] IDR interim (10/26/2015) 10:00am - 11:3… Jeffrey Haas
- Re: [Idr] IDR interim (10/26/2015) 10:00am - 11:3… Acee Lindem (acee)
- Re: [Idr] IDR interim (10/26/2015) 10:00am - 11:3… Susan Hares
- Re: [Idr] IDR interim (10/26/2015) 10:00am - 11:3… Jeffrey Haas
- [Idr] Regarding draft-vandevelde-idr-flowspec-pat… Lizhenbin
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… VAN DE VELDE, Gunter (Gunter)
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Robert Raszuk
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… VAN DE VELDE, Gunter (Gunter)
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Robert Raszuk
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Lucy yong
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Robert Raszuk
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Robert Raszuk
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Dongjie (Jimmy)
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… VAN DE VELDE, Gunter (Gunter)
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Susan Hares
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Susan Hares
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Lucy yong
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Susan Hares
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Robert Raszuk
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Robert Raszuk
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Gunter Van De Velde
- Re: [Idr] Regarding draft-vandevelde-idr-flowspec… Lucy yong