Subject: Re: [Idr] 答复: WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Wed, 25 Nov 2015 11:56:12 +0000

Many thanks to provide some extra context. The copy’d text from the draft is not really making it more clear.

Are you indicating that the signalled label is not used for forwarding? And its only purpose is to serve as a router local accounting container for a flow?

G/

From: Liangqiandeng <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 25 November 2015 at 12:41
To: "Bertrand Duvivier (bduvivie)" <[email-masked]<mailto:[email-masked]>>, Gunter Van de Velde <[email-masked]<mailto:[email-masked]>>, 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] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)

Hi Bertrand Duvivier and Gunter,

In this draft, the BGP router still allocates a label for a FlowSpec rule locally,  we just use a label to identify a traffic matching the flowspec rule.
so please don’t worry that “re-directicting to a remote label could be a quite random action”, there isn’t this type question.

The draft has described it as the following:
“So this document proposes that the BGP router supports to allocate a
   unique label to a FlowSpec rule, the forwarding path is still decided
   by the best-match unicast route for the embedded destination prefix
   or the best-match route to target IP in the 'redirect to IP' action.
   Figure 1 gives an example that FlowSpec rule bound with a label is
   disseminated in the network.

                  Option-B inter-AS connection
                  |<------AS1----->|    |<------AS2----->|
                  +-----+    +-----+    +-----+    +-----+
       VPN 1,IP1..| PE1 |====|ASBR1|----|ASBR2|====| PE2 |..VPN1,IP2
                  +-----+    +-----+    +-----+    +-----+
                     | LDP LSP1 |          | LDP LSP2 |
                     | -------> |          | -------> |
                     |-------BGP VPN Flowspec LSP---->|
                 (Label1)    (Label2)   (Label3)   (Label4)
                    Figure 1: Usage of FlowSpec with Label

  FlowSpec rule1 (injected in PE2):
       Filters:
          destination ip prefix:IP2/32
          source ip prefix:IP1/32
       Actions:
          traffic-marking: 1

  Labels allocated for FlowSpec1:
       Label4 allocated by PE2
       Label3 allocated by ASBR2
       Label2 allocated by ASBR1
       Label1 allocated by PE1

  PE2 disseminates the FlowSpec1 bound with Label4 to ASBR2.
  ASBR2 disseminates the FlowSpec1 bound with Label3 to ASBR1.
  ASBR1 disseminates the FlowSpec1 bound with Label2 to PE1.
”

“If the BGP router allocates a label for a FlowSpec rule and
   disseminates the labeled FlowSpec rule to the upstream peers, it can
   use the label to match the traffic identified by the FlowSpec rule in
   the forwarding plane.”

Thanks,
Qiandeng

发件人: Bertrand Duvivier (bduvivie) [mailto:[email-masked]]
发送时间: 2015年11月25日 19:19
收件人: VAN DE VELDE, Gunter (Gunter); Susan Hares; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)

Agree, labels are in general locally assign by remote nodes and not persistant and thus subject to change (we do have exceptions with global significant labels like prefix-SID), thus re-directicting to a remote label could be a quite random action.
Best Regards Bertrand Duvivier
Principal Engineer . Product Marketing

From: "<VAN DE VELDE>", "Gunter (Gunter)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 25 November 2015 08:24
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: Re: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)

When reading the text I am not clear how this would work and which component is allocating which label to use and how the LFIB on the different devices between network ingress and egress is constructed if Flowspec would be used to allocate labels in some way?

The use case for the proposal is a little vague as it seems to only indicate: “this facilitates monitoring and traffic
   statistics for FlowSpec rules.”.

Before considering for adoption, I think the use-case and operational flow charts should be more clearly documented in the text.

G/

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 24 November 2015 at 12:29
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)

This begins a 2 week adoption call for draft-liang-idr-bgp-flowspec-label-01.txt  which can be found at:

http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/

All authors should respond to this email whether the know of any IPR relating to this draft.   Please note that unless all authors respond to this email, the draft cannot be adopted as a WG draft.

This draft is part of the flow specification drafts considered at IETF 94, and on the mail list.  Out of that discussion, an inter-working draft will be create between the flow specification drafts.   If you are interested in this draft, but would like to see the inter-working draft, please indicate this in your comment.

Sue Hares

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Wed, 25 Nov 2015 15:09:05 +0000

Lian,

Still not clear. Could you explain the use-case better…

BGP flowspec signal  2 thinks:
A: flow(s) to match on
B: action(s) to takes

Are you suggesting to extend to match on labels ?

As I explained, label do have remote signification and are not persistant…

As an example, topology change may signal different label for the same destination IP address, thus matching on a label value doesn’t make sense for specific LSP going to a specific destination IP address.

Thanks,
Qiandeng

G/

Sue Hares