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

[Robert Raszuk <[e-mail]>]

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

> 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 <
[e-mail]> 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 <[e-mail]> 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 <
> [e-mail]> 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 <[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]> 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]> on behalf of Robert Raszuk <[e-mail]>
>>> Date: Monday 26 October 2015 at 17:41
>>> To: Gunter Van de Velde <[e-mail]>
>>> Cc: Lizhenbin <[e-mail]>, Susan Hares <[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
>>>
>>> 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]> 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]> on behalf of Lizhenbin <
>>>> [e-mail]>
>>>> Date: Monday 26 October 2015 at 16:51
>>>> To: Susan Hares <[e-mail]>, "[e-mail]" <[e-mail]>
>>>> Cc: "[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]
>>>> *主题:* [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/
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>>>
>>>
>>
>
>