Subject: [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update

From: "Susan Hares" <[email-masked]>
Date: Sun, 25 Oct 2015 10:06:36 -0400

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/

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/

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/

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/

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/

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/

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/

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/

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

Meeting number:            644 964 970 

Meeting password:         flow.in.nets

Join by phone

1-877-668-4493 Call-in toll free number (US/Canada)

1-650-479-3208 Call-in toll number (US/Canada)

Access code: 644 964 970

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 25 Oct 2015 11:13:34 -0400

Sue,

The interim shows as scheduled for the PM rather than AM time slot:

https://www.ietf.org/meeting/interim/idr-2015-10-26.txt

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 25 Oct 2015 18:57:48 +0000

Hi Jeff, 
If you look at the IDR archives, you’ll see that this was corrected.
Thanks,
Acee

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 25 Oct 2015 16:18:05 -0400

Jeff: 

It should be listed on the interim page correctly. 

Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Sunday, October 25, 2015 11:14 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update

Sue,

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 25 Oct 2015 19:41:07 -0400

Sue, the reason I point this out is this is the contents posted from the
interim page.

---

From: Lizhenbin <[email-masked]>
Date: Mon, 26 Oct 2015 15:51:32 +0000

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:[email-masked]] 代表 Susan Hares
发送时间: 2015年10月25日 22:07
收件人: [email-masked]
抄送: [email-masked]
主题: [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update

IDR WG members:

Sue

------------

webex infor:

Join by phone

---

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Mon, 26 Oct 2015 16:26:09 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Lizhenbin <[email-masked]<mailto:[email-masked]>>
Date: Monday 26 October 2015 at 16:51
To: Susan Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Gunter,

Best Regards,
Robin

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2015年10月25日 22:07
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update

IDR WG members:

Sue

------------

webex infor:

Join by phone

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Oct 2015 17:41:43 +0100

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

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) <
[email-masked]> 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 <[email-masked]> on behalf of Lizhenbin <
> [email-masked]>
> To: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复:
> IDR interim (10/26/2015) 10:00am - 11:30am ET update
>
> Hi Gunter,
>
> 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
>
> *发件人:* Idr [mailto:[email-masked] <[email-masked]>] *代表 *Susan
> Hares
> *发送时间:* 2015年10月25日 22:07
> *收件人:* [email-masked]
> *抄送:* [email-masked]
> *主题:* [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update
>
>
>
> IDR WG members:
>
>
>

---

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Mon, 26 Oct 2015 17:15:49 +0000

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: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Monday 26 October 2015 at 17:41
To: Gunter Van de Velde <[email-masked]<mailto:[email-masked]>>
Cc: Lizhenbin <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Gunter,

Now let's also notice that as you correctly state TE tunnels are rather custom crafted p2p entities.

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

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robin,

Thanks for your note.

Kind Regards,
G/

Hi Gunter,

Best Regards,
Robin

IDR WG members:

Sue

------------

webex infor:

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Oct 2015 18:34:54 +0100

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) <
[email-masked]> 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.
>
>    - 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
>
>    - 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)
>
>    - 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: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> To: Gunter Van de Velde <[email-masked]>
> Cc: Lizhenbin <[email-masked]>, Susan Hares <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: [Idr] Regarding
> draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015)
> 10:00am - 11:30am ET update
>
> Hi Gunter,
>
> Side question ... How are you going to provision mp2p TE ? Are you going
> to dust-off some proposals for it from the past ? Example:
>> Subject: [Idr] Regarding
>> draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015)
>> 10:00am - 11:30am ET update
>>
>> Hi Gunter,
>>

---

From: Gunter Van De Velde <[email-masked]>
Date: Mon, 26 Oct 2015 18:47:35 +0100

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 < [email-masked] [[email-masked]] > 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) < [email-masked] [[email-masked]] > 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: < [email-masked] [[email-masked]] > on behalf of Robert Raszuk < [email-masked] [[email-masked]] >
Date: Monday 26 October 2015 at 17:41
To: Gunter Van de Velde < [email-masked] [[email-masked]] >
Cc: Lizhenbin < [email-masked] [[email-masked]] >, Susan Hares < [email-masked] [[email-masked]] >, " [email-masked] [[email-masked]] " < [email-masked] [[email-masked]] >, " [email-masked] [[email-masked]] " < [email-masked] [[email-masked]] >
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) < [email-masked] [[email-masked]] > 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 < [email-masked] [[email-masked]] > on behalf of Lizhenbin < [email-masked] [[email-masked]] >
Date: Monday 26 October 2015 at 16:51
To: Susan Hares < [email-masked] [[email-masked]] >, " [email-masked] [[email-masked]] " < [email-masked] [[email-masked]] >
Cc: " [email-masked] [[email-masked]] " < [email-masked] [[email-masked]] >
Subject: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim
(10/26/2015) 10:00am - 11:30am ET update

Hi Gunter,

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:[email-masked] [[email-masked]] ] 代表 Susan Hares
发送时间 : 2015 年 10 月 25 日 22:07
收件人 : [email-masked] [[email-masked]]
抄送 : [email-masked] [[email-masked]]
主题 : [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update

IDR WG members:

Sue

------------

10:00 - 11:30am

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/]

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/]

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/]

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/]

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/]

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/]

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/]

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/]

11:15 - 11:30am

Monday, October 26, 2015

webex infor:

https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f
[https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f]

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
[email-masked] [[email-masked]]
https://www.ietf.org/mailman/listinfo/idr
[https://www.ietf.org/mailman/listinfo/idr]

---

From: Lucy yong <[email-masked]>
Date: Mon, 26 Oct 2015 18:48:55 +0000

Hi Gunter,

Sorry to chip in here. Please see inline below.

From: Idr [mailto:[email-masked]] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Monday, October 26, 2015 11:26 AM
To: Lizhenbin; Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//??: IDR interim (10/26/2015) 10:00am - 11:30am ET update

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.
[Lucy] agree. The tunnel-encaps draft is used to signal an IP tunnel, not a tunnel that is constructed by other protocol such as RSVP-TE. For a RSVP-TE tunnel, signaling the tunnel parameters used by the tail-end is not useful.  It needs to signal the tunnel parameters used by the head-end, which may be hard for the tunnel tail-end to do in some use case. However, in SDN controller case where BGP is used between SDN controller and router, SDN controller has the tunnel head-end parameters and can use BGP to signal the tunnel head-end parameter info to the routers. This is what draft-li-idr-mpls-path-programmer targets the use case.

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….
[Lucy] Yes. Draft-hao-idr-flowspect-redirect-tunnel specifies two types of tunnels, one is the IP tunnel that can be signaled by the tunnel encap. attribute specified in the tunnel-encap draft; another is the non-IP tunnel that can also be signaled by the attribute specified in the mpls-path-programmer drafts.

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.
[Lucy] You draft introduces the PATH ID that is global and represents a tunnel that is established by other protocol/manual. As a result, Central controller, BGP, and other protocol/routers need to be aware of the PATH ID and use it to reference a tunnel. Since the proposal relates to many components, it is necessary to explore more such service framework as a whole for an optimal solution.

Regards,
Lucy

Kind Regards,
G/

Hi Gunter,

Best Regards,
Robin

IDR WG members:

Sue

------------

webex infor:

Join by phone

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Oct 2015 20:10:49 +0100

> 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 <
[email-masked]> wrote:

> 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/
>
>
> <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 <[email-masked]> wrote:
>
> Gunter,
>
>>    - (there is no relationship that the destination is the same… just
>>    the redirect service is the same)
>>

---

From: Gunter Van De Velde <[email-masked]>
Date: Mon, 26 Oct 2015 20:33:20 +0100

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 <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Gunter,
> 
> 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) <[email-masked] <mailto:[email-masked]>> wrote:
> Robert,
> 
> 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
> 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)
> Manual config will make you go crazy very soon
> The above can be 100% orchestrated or a mix of manual/orchestrated could be used
> 
> From: <[email-masked] <mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked] <mailto:[email-masked]>>
> To: Gunter Van de Velde <[email-masked] <mailto:[email-masked]>>
> Cc: Lizhenbin <[email-masked] <mailto:[email-masked]>>, Susan Hares <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 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> 
> 
> On Mon, Oct 26, 2015 at 5:26 PM, VAN DE VELDE, Gunter (Gunter) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Robin,
> 
> Thanks for your note.
> 
> From:  Idr <[email-masked] <mailto:[email-masked]>> on behalf of Lizhenbin <[email-masked] <mailto:[email-masked]>>
> To: Susan Hares <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 发件人: Idr [mailto:[email-masked] <mailto:[email-masked]>] 代表 Susan Hares
> 发送时间: 2015年10月25日 22:07
> 收件人: [email-masked] <mailto:[email-masked]>
> 抄送: [email-masked] <mailto:[email-masked]>
>    https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ <https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/>
>   
> 
>    http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ <http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/>
>   
> 
>    
> 
>    http://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/ <http://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/>
>   
> 
>    
> 
>    http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ <http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/>
>   
> 
>  
> 
>   http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ <http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/>
>   
> 
>    http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/ <http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/>
>  
> 
>    http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/ <http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/>
>  
> 
>    http://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ <http://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/>
>   
> 
> https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f <https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f>
>  
> 
> 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
> 
>  
> 
>  
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> 
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Oct 2015 20:45:39 +0100

> On PE2 the localised mapping of PATH_ID1 goes to Tunnel 2

That would be highly confusing operationally.

> 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.

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 <
[email-masked]> wrote:

>>> Yeah, BGP is indeed p2mp relationship… This is important to keep in
>>> mind, and that it is exactly why PATH-ID makes sense.
>>>
>>> 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 ?
>>>
>>>> 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.
>>>>

---

From: Gunter Van De Velde <[email-masked]>
Date: Mon, 26 Oct 2015 20:52:21 +0100

> On 26 Oct 2015, at 20:45, Robert Raszuk <[email-masked]> wrote:
> 

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 :-)

> 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. 
> 
> On Mon, Oct 26, 2015 at 8:33 PM, Gunter Van De Velde <[email-masked] <mailto:[email-masked]>> wrote:
>> On 26 Oct 2015, at 20:10, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 27 Oct 2015 02:09:20 +0000

Hi Gunter,

Sorry to chime in here. I have some similar concerns as Robert on this mechanism.

Since BGP advertisement is p2mp, Flow Spec NLRI with the same PATH-ID would be advertised to all BGP speakers. As illustrated in your example, on different nodes this PATH-ID would be mapped to different actions. Perhaps you could elaborate on what “a single redirect service” means on different nodes so that they can be represented by the identical PATH-ID?

Besides, my feeling is this 32-bit or 128-bit PATH-ID is so abstract that it can cover quite broad meanings (even more than redirect), perhaps that’s why there are comments on the relationship between PATH-ID and other existing/new actions. However the real challenge IMO is to map the abstract PATH-ID to specific actions on each node. I’m not sure whether/how this can be orchestrated, as manual configuration would make you crazy.

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Tuesday, October 27, 2015 1:16 AM
To: Robert Raszuk
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Robert,

G/

Hi Gunter,

Cheers,
R.

Thanks for your note.

Kind Regards,
G/

Hi Gunter,

Best Regards,
Robin

IDR WG members:

Sue

------------

webex infor:

Join by phone

---

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Tue, 27 Oct 2015 07:59:40 +0000

Hi Jie,

The trick is to manage a single PATH id across multiple nodes, but it is an abstract meta-data that gets you to a tunnel.

Keeping track and management of a instance of a network wide variable using orchestration is the minimum a orchestration system should be able to do and is one of the reasons for their existence… For an orchestration system it is a simple task.

G/

From: "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 27 October 2015 at 03:09
To: Gunter Van de Velde <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Gunter,

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Tuesday, October 27, 2015 1:16 AM
To: Robert Raszuk
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Robert,

G/

Hi Gunter,

Cheers,
R.

Thanks for your note.

Kind Regards,
G/

Hi Gunter,

Best Regards,
Robin

IDR WG members:

Sue

------------

webex infor:

Join by phone

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 27 Oct 2015 14:28:23 -0400

Gunter: 

Can you let me know the difference between the Path ID in your proposal and Robin’s Forwarding ID that is a generalized segment ID? 

Sue Hares

From: VAN DE VELDE, Gunter (Gunter) [mailto:[email-masked]] 
Sent: Monday, October 26, 2015 12:26 PM
To: Lizhenbin; Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Robin,

Thanks for your note.

Kind Regards,

G/

From:  Idr <[email-masked]> on behalf of Lizhenbin <[email-masked]>

Hi Gunter,

 

Best Regards,

Robin

 

IDR WG members: 

Sue 

------------

10:00 - 11:30am 

   Time: 10:05-10:15

   Speaker: Weiguo Hao

   Time: 10:15 - 10:25 

   

   Time: 10:25- 10:35

   

   Speaker: Weiguo Hao

   Duration: 10:35-10:40 

 

   Speaker: 

   Duration: 10:40-10:45 

   presenter: Jianjie You

   time: 10:45-10:55

   Speaker: Zhenbin Li

   Duration: 10:55-11:05 

   Speaker: Shunwan Zhuang

   Duration: 11:05 - 11:15 

    11:15 - 11:30am 

 Monday, October 26, 2015 

webex infor: 

 

Join by phone

Access code: 644 964 970

---

From: Gunter Van De Velde <[email-masked]>
Date: Tue, 27 Oct 2015 21:12:29 +0100

Hi Sue,

Would you know where to find Forwarding ID described in draft-hao-idr-flowspec-redirect-tunnel to make assessment? 
There is no mentioning of this concept at all in the document? Alternatively, what i found is signalling of tunnel end-point (IPv4/IPv6) and 
some tunnel setup information (tunnel encap attribute and a new MPP TE tunnel attribute).

Brgds,
G/

> On 27 Oct 2015, at 19:28, Susan Hares <[email-masked]> wrote:
> 
> Gunter:
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 27 Oct 2015 19:30:18 -0400

Gunter: 

Robin’s proposal is http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/

See my attached comparison from the interim.  You can also download Robin’s slides from the interim.   

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Tuesday, October 27, 2015 4:12 PM
To: Susan Hares
Cc: idr wg; [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Sue,

Brgds,

G/

 

Gunter: 

Sue Hares

Hi Robin,

Thanks for your note.

Kind Regards,

G/

Hi Gunter,

 

Best Regards,

Robin

 

IDR WG members: 

Sue 

------------

10:00 - 11:30am 

   Time: 10:05-10:15

   Speaker: Weiguo Hao

   Time: 10:15 - 10:25 

   

   Time: 10:25- 10:35

   

   Speaker: Weiguo Hao

   Duration: 10:35-10:40 

 

   Speaker: 

   Duration: 10:40-10:45 

   presenter: Jianjie You

   time: 10:45-10:55

   Speaker: Zhenbin Li

   Duration: 10:55-11:05 

   Speaker: Shunwan Zhuang

   Duration: 11:05 - 11:15 

    11:15 - 11:30am 

 Monday, October 26, 2015 

webex infor: 

 

Join by phone

Access code: 644 964 970

---

From: Lucy yong <[email-masked]>
Date: Wed, 28 Oct 2015 00:38:03 +0000

Hi Gunter,

The hao’s draft specifies the flowspec to be redirected to a tunnel. It classifies tunnel into two types: IP tunnel and non-IP tunnel. For an IP tunnel, it proposes use of the tunnel-encapsulation attribute specified in the tunnel-encaps draft; for a non-IP tunnel, it proposes use of the attributes specified in draft-li-idr-mpls-path-programming, to convey the tunnel info. The hao’s draft does not intend to use BGP to signal the tunnel info for the tunnel set-up; it specifies how BGP advertises the flowspec w/ associated tunnel so the flow packets can be redirected to the tunnel.

Thanks,
Lucy

From: Idr [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Tuesday, October 27, 2015 3:12 PM
To: Susan Hares
Cc: idr wg; [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//??: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Sue,

Brgds,
G/

On 27 Oct 2015, at 19:28, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Gunter:

Sue Hares

From: VAN DE VELDE, Gunter (Gunter) [mailto:[email-masked]]
Sent: Monday, October 26, 2015 12:26 PM
To: Lizhenbin; Susan Hares; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Robin,

Thanks for your note.

Kind Regards,
G/

Hi Gunter,

Best Regards,
Robin

IDR WG members:

Sue

------------

webex infor:

Join by phone

---

From: Gunter Van De Velde <[email-masked]>
Date: Wed, 28 Oct 2015 10:37:49 +0100

Hi Sue,

[Please indicate when you are speaking as IDR chair or when you are speaking as contributor/affiliation… i am confused]

I did a search for forwarding ID in the referenced document and i do not see it?

You clearly understand that draft-vandevelde-idr-flowspec-path-redirect and draft-li-idr-mpls-path-programming are orthogonal to each other, not?
“draft-li-idr-mpls-path-programming " specifies how BGP uses attributes to signal a tunnel and how a tunnel is constructed through the network, while on the other end of the 
spectrum draft-vandevelde-idr-flowspec-path-redirect specifies flowspec based traffic steering onto a redirect path and signals no tunnel attributes at all.

In draft-vandevelde-idr-flowspec-path-redirect the local PATH_ID table can be constructed by many means and is outside the scope of the document:

* draft-li-idr-mpls-path-programming
* manual config
* netconf/yang
* traditional routing
* voodoo 
* etc...

The end result: redirect-to-path and draft-li-idr-mpls-path-programming are orthogonal to each other.

Kind Regards,
G/

> On 28 Oct 2015, at 00:30, Susan Hares <[email-masked]> wrote:
> 
> Gunter: 
>  
> Robin’s proposal is http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/ <http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/>
>  
> From: Idr [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gunter Van De Velde
> Cc: idr wg; [email-masked] <mailto:[email-masked]>
>> On 27 Oct 2015, at 19:28, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Gunter: 
>>  
>> From: VAN DE VELDE, Gunter (Gunter) [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Lizhenbin; Susan Hares; [email-masked] <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>
> <Hares-Discussion of Flowspec.pdf>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 28 Oct 2015 05:50:08 -0400

Gunter: 

My apologies – since the slide I referenced was the chair’s discussion generating slide – I did not put <IDR chair hat on> - I should have. 

<chair hat on> 

My chair’s discussion was to inspire conversation on you perception of the path-id versus the draft-li-mpls-path-programming. 

I was looking to solicit the following comment from you.  

“You clearly understand that draft-vandevelde-idr-flowspec-path-redirect and draft-li-idr-mpls-path-programming are orthogonal to each other, not?” 

My job as chair is to get people talking about their view of the other proposal. 

<chair hat off> 

The issue is that “path-id” and your concepts of paths is similar to many of the MPLS and segment routing path ids.   Draft-li-idr-mpls-path-programming seeks to generalize segment routing (see Robin’s slides) using a variety of BGP and MPLS.    

As Lucy’s slides pointed out – we have an IP and non-IP traffic.  My understanding is that your path-id is for just IP traffic.  You comment below would suggest both. 

Best wishes, 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Wednesday, October 28, 2015 5:38 AM
To: Susan Hares
Cc: idr wg; [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Sue,

* manual config

* netconf/yang

* traditional routing

* voodoo 

* etc...

Kind Regards,

G/

Gunter: 

Robin’s proposal is  <http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/> http://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/

Sue 

From: Idr [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Tuesday, October 27, 2015 4:12 PM
To: Susan Hares
Cc: idr wg;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Sue,

Brgds,

G/

 

On 27 Oct 2015, at 19:28, Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

Gunter: 

Sue Hares

From: VAN DE VELDE, Gunter (Gunter) [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Monday, October 26, 2015 12:26 PM
To: Lizhenbin; Susan Hares;  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Robin,

Thanks for your note.

Kind Regards,

G/

From:  Idr < <mailto:[email-masked]> [email-masked]> on behalf of Lizhenbin < <mailto:[email-masked]> [email-masked]>
Date: Monday 26 October 2015 at 16:51
To: Susan Hares < <mailto:[email-masked]> [email-masked]>, " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]>
Cc: " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]>
Subject: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Gunter,

 

Best Regards,

Robin

 

发件人: Idr [ <mailto:[email-masked]> mailto:[email-masked]] 代表 Susan Hares
发送时间: 2015年10月25日 22:07
收件人:  <mailto:[email-masked]> [email-masked]
抄送:  <mailto:[email-masked]> [email-masked]
主题: [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update

IDR WG members: 

Sue 

------------

10:00 - 11:30am 

   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/

   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/

   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/

   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/

   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/

   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/

   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/

   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/

    11:15 - 11:30am 

 Monday, October 26, 2015 

webex infor: 

 <https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f> https://ietf.webex.com/ietf/j.php?MTID=mae6cf241d3adf214033e599c3ff3143f

 

Join by phone

Access code: 644 964 970

_______________________________________________
Idr mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/idr> https://www.ietf.org/mailman/listinfo/idr

---

From: Gunter Van De Velde <[email-masked]>
Date: Wed, 28 Oct 2015 11:06:26 +0100

Many thanks for the table, due to the extra context i understand better how this table should be consumed and i realise that 
the embedded comparison has a tiny mistake, resulting in the unlucky consequence it provides mayor misleadings regarding 
traffic-steering-into-a-tunnel proposals.

It really makes no technical sense to classify draft-vandevelde-idr-flowspec-path-redirect together with draft-li-idr-mpls-path-programming-02 as they are totally orthogonal to each other.

The better bucket for draft-vandevelde-idr-flowspec-path-redirect would be:

Traffic steering (or even your classification for ‘tunnels’ seems more appropriate)
  draft-vandevelde-idr-flowspec-path-redirect
  draft-hao-idr-flowspec-redirect-tunnel

Both of these drafts use flowspec to steer traffic into a tunnel (either IP or something else).
In draft-hao-idr-flowspec-redirect-tunnel the steering-to-tunnel info and tunnel construct info is signalled together with the flowspec NLRI (e.g. additional attributes (MPP or encap-attribute)).
In draft draft-vandevelde-idr-flowspec-path-redirect flowspec simply signals a redirect PATH_ID used as meta-data to identify a locallised tunnel or redirect construct in a localised PATH_ID table. 
This process allows that a tunnel construct is completely decoupled from flowspec signalling (there are many ways to construct this local table: draft-li-idr-mpls-path-programming, encap-attribute, manual config, etc…).

Brgds,
G/

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 28 Oct 2015 11:07:22 +0100

Hi Sue,

> The issue is that “path-id” and your concepts of paths
> is similar to many of the MPLS and segment routing path ids.

Well as it turns out from our discussion yesterday Gunter clarified that
the PATH_ID he used is just an reference to an indirection.

Hence as such it really has not much in common with what most folks
understand by PATH_ID.

Perhaps if he just renames it to something else (less confusing) his draft
will go forward quite smooth :)

Cheers,
R.

On Wed, Oct 28, 2015 at 10:50 AM, Susan Hares <[email-masked]> wrote:

> Gunter:
>
>
>
> My apologies – since the slide I referenced was the chair’s discussion
> generating slide – I did not put <IDR chair hat on> - I should have.
>
>
>
> <chair hat on>
>
> My chair’s discussion was to inspire conversation on you perception of the
> path-id versus the draft-li-mpls-path-programming.
>
>
>
> “You clearly understand that draft-vandevelde-idr-flowspec-path-redirect
> and draft-li-idr-mpls-path-programming are orthogonal to each other, not?”
>
>
>
> The issue is that “path-id” and your concepts of paths is similar to many
> of the MPLS and segment routing path ids.
>  Draft-li-idr-mpls-path-programming seeks to generalize segment routing
> (see Robin’s slides) using a variety of BGP and MPLS.
>
>
>
> As Lucy’s slides pointed out – we have an IP and non-IP traffic.  My
> understanding is that your path-id is for just IP traffic.  You comment
> below would suggest both.
>
>
>
> Best wishes,
>
> Sue
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Gunter Van De
> Velde
> *Sent:* Wednesday, October 28, 2015 5:38 AM
>
> *To:* Susan Hares
> *Cc:* idr wg; [email-masked]
> *Subject:* Re: [Idr] Regarding
> draft-vandevelde-idr-flowspec-path-redirect//
> 答复: IDR interim (10/26/2015) 10:00am - 11:30am ET update
>
>
>
> Hi Sue,
>
>
>
> [Please indicate when you are speaking as IDR chair or when you are
> speaking as contributor/affiliation… i am confused]
>
>
>
> You clearly understand that draft-vandevelde-idr-flowspec-path-redirect
> and draft-li-idr-mpls-path-programming are orthogonal to each other, not?
>
> “draft-li-idr-mpls-path-programming " specifies how BGP uses attributes to
> signal a tunnel and how a tunnel is constructed through the network, while
> on the other end of the
>
> spectrum draft-vandevelde-idr-flowspec-path-redirect specifies flowspec
> based traffic steering onto a redirect path and signals no tunnel
> attributes at all.
>
>
>
> In draft-vandevelde-idr-flowspec-path-redirect the local PATH_ID table can
> be constructed by many means and is outside the scope of the document:
>
>
>
> Robin’s proposal is
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Gunter Van De Velde
> *Sent:* Tuesday, October 27, 2015 4:12 PM
> *To:* Susan Hares
> *Cc:* idr wg; [email-masked]
> *Subject:* Re: [Idr] Regarding
> There is no mentioning of this concept at all in the document? Alternatively,
> what i found is signalling of tunnel end-point (IPv4/IPv6) and
>
> Can you let me know the difference between the Path ID in your proposal
> and Robin’s Forwarding ID that is a generalized segment ID?
>
>
>
> Sue Hares
>
>
>
> *From:* VAN DE VELDE, Gunter (Gunter) [
> mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, October 26, 2015 12:26 PM
> *To:* Lizhenbin; Susan Hares; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] Regarding
> *From: * Idr <[email-masked]> on behalf of Lizhenbin <
> [email-masked]>
> *Date: *Monday 26 October 2015 at 16:51
> *To: *Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *[Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//答复:
> *发件人**:* Idr [mailto:[email-masked] <[email-masked]>] *代表* Susan
> Hares
> *发送时间**:* 2015年10月25日 22:07
> *收件人**:* [email-masked]
> *抄送**:* [email-masked]
> *主题**:* [Idr] IDR interim (10/26/2015) 10:00am - 11:30am ET update
>
>
>
> IDR WG members:
>
>
>

---

From: Gunter Van De Velde <[email-masked]>
Date: Wed, 28 Oct 2015 11:17:36 +0100

Robert,

Happy to change the “PATH_ID” name into some other name if it brings down the misunderstandings…
Would you have a proposal? 

G/

> On 28 Oct 2015, at 11:07, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Sue,
> 
> Well as it turns out from our discussion yesterday Gunter clarified that the PATH_ID he used is just an reference to an indirection. 
> 
> Hence as such it really has not much in common with what most folks understand by PATH_ID. 
> 
> Perhaps if he just renames it to something else (less confusing) his draft will go forward quite smooth :) 
> 
> Cheers,
> R.
> 
> 
> 
> 
> On Wed, Oct 28, 2015 at 10:50 AM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
> Gunter:
> 
>  
> 
> Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//
> On 28 Oct 2015, at 00:30, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
> Gunter: 
> 
>  
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 28 Oct 2015 11:25:04 +0100

Let's talk more about it ...

For example the C bit in yr draft which indicates data "copy" or "tee" is
applicable to already existing redirect action hence it may be good to lift
it higher and define as standalone action attribute.

Perhaps it would be great to document in email or draft what specific
applications are not possible with today's redirect based on the RT to a
new table and will be enabled with your new table mapping.

Cheers,
R.

On Wed, Oct 28, 2015 at 11:17 AM, Gunter Van De Velde <
[email-masked]> wrote:

>> My chair’s discussion was to inspire conversation on you perception of
>> the path-id versus the draft-li-mpls-path-programming.
>>
>>
>>
>> “draft-li-idr-mpls-path-programming " specifies how BGP uses attributes
>> to signal a tunnel and how a tunnel is constructed through the network,
>> while on the other end of the
>>
>> In draft-vandevelde-idr-flowspec-path-redirect the local PATH_ID table
>> can be constructed by many means and is outside the scope of the document:
>>
>>
>>
>> draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim
>> draft-vandevelde-idr-flowspec-path-redirect//答复: IDR interim
>> *Subject: *[Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//

---

From: Gunter Van De Velde <[email-masked]>
Date: Wed, 28 Oct 2015 11:30:58 +0100

Hi Lucy,

Inside the the abstract of draft-hao-idr-flowspec-redirect-tunnel-00 we read: 

   The redirected tunnel information and target IP address are encoded
   in BGP Path Attribute [TUNNELENCAPS] [MPP] that is carried in the
   BGP flow-spec UPDATE.

This indicates in Hao proposal that Flowspec is to signal information regarding tunnel constructs, not?

G/

> On 28 Oct 2015, at 01:38, Lucy yong <[email-masked]> wrote:
> 
> Hi Gunter,
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 28 Oct 2015 21:32:37 +0000

Hi Gunter,

Hoa’s draft is not about that flowspec is to signal information regarding tunnel constructs. It is about distributing a flowspec that is associated with redirect-to-tunnel action; the draft proposes that the related tunnel information is carried in BGP attribute. For an IP tunnel, the tunnel encapsulation attribute in [TUNNELENCAPS] is used; for a non-IP tunnel, the tunnel attribute in [MPP] is used.

Thanks,
Lucy

From: Gunter Van De Velde [mailto:[email-masked]]
Sent: Wednesday, October 28, 2015 5:31 AM
To: Lucy yong
Cc: Susan Hares; idr wg; [email-masked]
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//??: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Lucy,

   BGP flow-spec UPDATE.

G/

On 28 Oct 2015, at 01:38, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gunter,

Thanks,
Lucy

From: Idr [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Tuesday, October 27, 2015 3:12 PM
To: Susan Hares
Cc: idr wg; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Regarding draft-vandevelde-idr-flowspec-path-redirect//??: IDR interim (10/26/2015) 10:00am - 11:30am ET update

Hi Sue,

Brgds,
G/

Gunter:

Sue Hares

Hi Robin,

Thanks for your note.

Kind Regards,
G/

Hi Gunter,

Best Regards,
Robin

IDR WG members:

Sue

------------

webex infor:

Join by phone