Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

[Robert Raszuk <[e-mail]>]

Jim,

It is ok to use bgp as database distribution protocol and to carry more
then pure routing/reachability state. We are indeed past that point. But
only to the extend where distributed information is usefull at multiple end
points.

However I do not see p2mp nature of BGP distribution to generally fit
policy or configuration needs.

Those are very often targeted to specific end point and I do not think that
sending them to all or for that matter filtering from all-1 with say RTC is
really a wise approach.

Rgs,
R.
 On Sep 2, 2014 7:06 AM, "UTTARO, JAMES" <[e-mail]> wrote:

> Comments In-Line
>
> Jim Uttaro
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, September 01, 2014 11:22 AM
> To: Haoweiguo; UTTARO, JAMES; '[e-mail]'; '[e-mail]'
> Cc: liuweihang
> Subject: RE: New Version Notification for
> draft-hao-idr-flowspec-evpn-00.txt
>
> [weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet
> header but also IP header can be used for traffic filtering.  I think our
> draft can cover this scenario. In the draft, component types include both
> IP and ethernet part, IP component types are inherited from RFC[5575], MAC
> componet types are newly defined. So only one address family is needed for
> IP and Ethernet traffic filtering.
>
> [SLI] Right, that's one possibility, the other one could be to not create
> a new AF for MAC FS but just extend the current FS address-families (VPN
> and non VPN) with MAC component types and new actions.
> The main question in term of protocol design is to we want to keep
> filtering AF agnostic (single FS AF for all type of flows) or do we need to
> keep separate FS AFs ?
> [Jim U>] This comes back to a more basic question. Should an AF be defined
> that communicates non-routing state? As an ex, VPLS BGP, FS, RTC the list
> goes on are all delineated by AF.. At some point we need to acknowledge
> that we are using BGP as a general distribution protocol and have the
> design/spec reflect that. IMO this means separating by configuration type
> of actions that do not require a global invariant and routing which does.
> The way taken for the moment is to have separate ones, we can see that
> IPv6 FS is currently defined as a new couple of AFI/SAFI but is it the good
> way to do ? I don't remember if this has been discussed or not when
> defining FS IPv6 ?
> I'm wondering if we cannot make FlowSpec working as IPFIX for the flow
> definition.
>
>
>
> -----Original Message-----
> From: Haoweiguo [mailto:[e-mail]]
> Sent: Monday, September 01, 2014 13:51
> To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; '[e-mail]'; '
> [e-mail]'
> Cc: liuweihang
> Subject: 答复: New Version Notification for
> draft-hao-idr-flowspec-evpn-00.txt
>
> Hi Stephane,
> Pls see my reply inline with [weiguo2] below.
> Thanks
> weiguo
>
> ________________________________________
> 发件人: [e-mail] [[e-mail]]
> 发送时间: 2014年9月1日 17:27
> 收件人: Haoweiguo; UTTARO, JAMES; '[e-mail]'; '[e-mail]'
> 抄送: liuweihang
> 主题: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt
>
> [weiguo]: Thanks. But MAC filters maybe not applicable to IPV4 &VPNv4,
> because in this case, MAC information will be changed on different PE
> devices, a single ACL rule can't identify a consistant flow at different PE
> devices. So in IP network, flow-spec can only be defined using IP related
> information.
> [SLI] I agree with your point but I was thinking about a future (hope it
> will happen :) when we will be able to offer L2 and L3 services on the same
> plug (including same VLAN, sort of concurrent routing & bridging
> interface). In this situation, is it good to use two address families to
> filter the different services ? Why not using only one ...
>
> [weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet
> header but also IP header can be used for traffic filtering.  I think our
> draft can cover this scenario. In the draft, component types include both
> IP and ethernet part, IP component types are inherited from RFC[5575], MAC
> componet types are newly defined. So only one address family is needed for
> IP and Ethernet traffic filtering.
>
> [weiguo]: RD usage has no difference with original BGP VPN definication.
> Can you give me some more clarifications?
> [SLI] Right, but RFC5575 precises that RD is part of NLRI for VPN :
> "The NLRI format for this address family consists of a fixed-length
>    Route Distinguisher field (8 bytes) followed by a flow specification,
>    following the encoding defined in this document.  The NLRI length
>    field shall include both the 8 bytes of the Route Distinguisher as
>    well as the subsequent flow specification.
> "
> In your document , I can't see this ... as you are defining a new NLRI,
> you need to precise the format.
>
> [weiguo2]: OK. In our draft, the format is same with RFC5575, I can add
> the same description to make it more clear.
>
>
> Stephane
>
>
>
> -----Original Message-----
> From: Haoweiguo [mailto:[e-mail]]
> Sent: Saturday, August 23, 2014 09:08
> To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; '[e-mail]'; '
> [e-mail]'
> Cc: liuweihang
> Subject: 答复: New Version Notification for
> draft-hao-idr-flowspec-evpn-00.txt
>
> Hi Stephane,
> Thanks for your detail comments. Pls see my reply inline with [weiguo]
> below.
> weiguo
>
> ________________________________________
> 发件人: [e-mail] [[e-mail]]
> 发送时间: 2014年8月22日 16:22
> 收件人: Haoweiguo; UTTARO, JAMES; '[e-mail]'; '[e-mail]'
> 抄送: liuweihang
> 主题: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt
>
> Hi,
>
> I think this is a valuable addition, but I would like to see these MAC
> filters being applicable also to IPv4 plugs (FS IPv4 & VPNv4)
> [weiguo]: Thanks. But MAC filters maybe not applicable to IPV4 &VPNv4,
> because in this case, MAC information will be changed on different PE
> devices, a single ACL rule can't identify a consistant flow at different PE
> devices. So in IP network, flow-spec can only be defined using IP related
> information.
>
> Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2
> interface may be interested by such filter (VPLS, basic L2 switching ...).
> [weiguo]: Yes, I agree. Firstly i propose Ethernet flow-spec only in EVPN
> network, because flows-pec relies on BGP protocol and EVPN has BGP control
> plane, so it will be easy to deploy BGP flowspec in EVPN network. If we
> want to deploy the flow-spec in VPLS network, normally VPLS only relies on
> LDP protocol, additional protocol of BGP flow-spec should be deployed for
> MAC filtering.
> If the community thinks it is necessary to introduce ethernet flow-spec
> for all L2 interface, i can update this part to let it not be restricted to
> EVPN.
>
> Route distinguisher may be is missing ...
> [weiguo]: RD usage has no difference with original BGP VPN definication.
> Can you give me some more clarifications?
>
> Now more globally, may be it's time to think more globally about the
> evolution of FS. I pretty see FS evolution largely beyond DDoS domain. FS
> is a very good protocol for SDN applications. The question behind is do we
> really need to work with multiple address families for each type of
> "service"/"interface type" to filter or do we need to have a more global
> model where we would be able to put any type of filter any where and apply
> multiple actions (openflow like FS). Compared to openflow, FS has the magic
> to enable multipoint distribution of actions.
>
> [weiguo]: Yes, BGP flow-spec can be applicable for some SDN applications.
> It has more potential to do more attactive things.
>
> Best Regards,
>
> Stephane
>
>
> -----Original Message-----
> From: Idr [mailto:[e-mail]] On Behalf Of Haoweiguo
> Sent: Thursday, August 21, 2014 04:11
> To: UTTARO, JAMES; '[e-mail]'; '[e-mail]'
> Cc: liuweihang
> Subject: [Idr] 答复: New Version Notification for
> draft-hao-idr-flowspec-evpn-00.txt
>
> Hi Jim,
> Thanks for your comments. The BGP Flowspec procedures is illustrated as
> following:
>
>                                           EVPN FlowSpec Session
>       EVPN FlowSpec Session
> DDOS Detection Appliance--------------------------Egress
> PE-----------------------------Ingress PE------CE2
>
>                |
>
>             CE1 DDOS Detection Appliance establishes EVPN flowspec session
> with Egress PE, it detects DDOS attack traffic and generate ACL rule, the
> ACL rule is announced to Egress PE through EVPN flowspec protocol, then the
> egress PE announces it to ingress PE, finally ingress PE installs the ACL
> rule for traffic filtering.
> DDOS Detection Appliance only needs to support EVPN flowspec function, it
> doesn't need to support basic EVPN function.
> Thanks
> weiguo
> ________________________________________
> 发件人: UTTARO, JAMES [[e-mail]]
> 发送时间: 2014年8月21日 0:29
> 收件人: Haoweiguo; '[e-mail]'; '[e-mail]'
> 抄送: liuweihang
> 主题: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt
>
> Weiguo,
>
>         I would like to better understand how a remote PE will "learn"
> that it needs to deliver a FS path to the ingress PE?? It cannot come from
> the CE as that is data plane learning. I would think that all FS paths have
> to be disseminated by a centralized controller.
>
> Jim Uttaro
>
> -----Original Message-----
> From: Idr [mailto:[e-mail]] On Behalf Of Haoweiguo
> Sent: Tuesday, August 19, 2014 8:31 PM
> To: [e-mail]; [e-mail]
> Cc: liuweihang
> Subject: [Idr] 答复: New Version Notification for
> draft-hao-idr-flowspec-evpn-00.txt
>
> Hi All,
> We have submitted a draft of " Dissemination of Flow Specification Rules
> for EVPN".  I will appriciate if you can give us some suggestions and
> comments.
> Thanks
> weiguo
>
> ________________________________________
> 发件人: [e-mail] [[e-mail]]
> 发送时间: 2014年8月20日 8:20
> 收件人: Zhuangshunwan; Haoweiguo; liuweihang; Zhuangshunwan; liuweihang;
> Haoweiguo
> 主题: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt
>
> A new version of I-D, draft-hao-idr-flowspec-evpn-00.txt
> has been successfully submitted by Weiguo Hao and posted to the IETF
> repository.
>
> Name:           draft-hao-idr-flowspec-evpn
> Revision:       00
> Title:          Dissemination of Flow Specification Rules for EVPN
> Document date:  2014-08-20
> Group:          Individual Submission
> Pages:          7
> URL:
> http://www.ietf.org/internet-drafts/draft-hao-idr-flowspec-evpn-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn/
> Htmlized:       http://tools.ietf.org/html/draft-hao-idr-flowspec-evpn-00
>
>
> Abstract:
>    This document defines BGP flow-spec extension for Ethernet traffic
>    filtering in EVPN network. A new BGP NLRI type (AFI=25, SAFI=TBD)
>    value is proposed to identify EVPN flow-spec application. A new
>    subset of component types and extended community also are defined.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>