Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

[Gunter Van De Velde <[e-mail]>]

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 < [e-mail] [[e-mail]] > 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) < [e-mail] [[e-mail]] > 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: < [e-mail] [[e-mail]] > on behalf of Robert Raszuk < [e-mail] [[e-mail]] >
Date: Monday 26 October 2015 at 17:41
To: Gunter Van de Velde < [e-mail] [[e-mail]] >
Cc: Lizhenbin < [e-mail] [[e-mail]] >, Susan Hares < [e-mail] [[e-mail]] >, " [e-mail] [[e-mail]] " < [e-mail] [[e-mail]] >, " [e-mail] [[e-mail]] " < [e-mail] [[e-mail]] >
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) < [e-mail] [[e-mail]] > 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 < [e-mail] [[e-mail]] > on behalf of Lizhenbin < [e-mail] [[e-mail]] >
Date: Monday 26 October 2015 at 16:51
To: Susan Hares < [e-mail] [[e-mail]] >, " [e-mail] [[e-mail]] " < [e-mail] [[e-mail]] >
Cc: " [e-mail] [[e-mail]] " < [e-mail] [[e-mail]] >
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:[e-mail] [[e-mail]] ] 代表 Susan Hares
发送时间 : 2015 年 10 月 25 日 22:07
收件人 : [e-mail] [[e-mail]]
抄送 : [e-mail] [[e-mail]]
主题 : [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:[phone]] Call-in toll free number (US/Canada)

1-650-479-3208 [tel:[phone]] Call-in toll number (US/Canada)

Access code: 644 964 970






_______________________________________________
Idr mailing list
[e-mail] [[e-mail]]
https://www.ietf.org/mailman/listinfo/idr
[https://www.ietf.org/mailman/listinfo/idr]