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

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Dec 2015 10:22:47 +0100

Gunter,

​See inline ...​

1) assumed is that global labels are used, however it is nowhere mentioned
> explicitely in the draft
​Since there is no formal definition of "global label"​ in any IETF RFC
such statement can not be added as normative to the new specification.
Sorry.

2) with global labels come applicability area being only SPRING based
> networks, please add this to the technology usability section
>
​That is incorrect technically. The draft is equally applicable to basic
L3VPNs to match on VPN label either as second in the stack or first (case
of Inter-as option B at ASBRs).

The draft already provides text on the above applicability in section 1.

> 3) Traditional best path selection is used to find best NLRI, however a
> different to IGP label is pushed ... The draft does not describe measures
> to guaranty that the pushed label represents the same destination node.
>

​Sorry but this extension does not distribute labels to be pushed on the
packets as the IGP or bottom label on the stack. ​It does however provide
means to apply demux label for application layer (the example in the draft
is EPE). I personnaly see nothing wrong with such approach.

4) why is this solution better as using traditional flowspec redirect to
> VRF (with exact one route in VRF)? In this case telemetry for flowspec
> redirect can be done with existing technology ... Nothing new is required...
>

​That's comparing apples to oranges ... ​The vrf redirection is a local
action. Imagine that packets have been redirected to local vrf. Now within
such local VRF you have entered static route to send packets say to some
collector or exit ASBR.

But if you would like to further add a demux value which such collector or
exit ASBR would use to switch packets to proper context this is where this
extension can be used.

​Best,
R.​

Understanding the above considerationd i do not feel the current draft is
> ready for adoption.
>
> Ciao,,
> G/
>
>
> Sent using CloudMagic Email
> <https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.0.67&pv=6.0&source=email_footer_2>
> On Tue, Dec 01, 2015 at 11:16 AM, Wesley Eddy <[email-masked]> wrote:
>
> On 11/24/2015 6:29 AM, Susan Hares wrote:
>
> 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/
>
>
>
>
> I agree with other comments that this is a useful extension.
>
> It would be good in the draft to clarify the assumptions about global (or
> at least mutual) significance of the labels, but this is more about clearly
> describing its use and operation than any impact to the protocol spec.
>
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Dec 2015 10:23:10 +0100

Support. Not aware about any IPR.

Thx,
r.

On Tue, Nov 24, 2015 at 12:29 PM, Susan Hares <[email-masked]> wrote:

> 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: Gunter Van De Velde <[email-masked]>
Date: Tue, 01 Dec 2015 17:45:52 +0800

Well….

> On 01 Dec 2015, at 17:22, Robert Raszuk <[email-masked]> wrote:
> 
> Gunter,
> 
> ​See inline ...​
> 
> 1) assumed is that global labels are used, however it is nowhere mentioned explicitely in the draft
> 
> ​Since there is no formal definition of "global label"​ in any IETF RFC such statement can not be added as normative to the new specification. Sorry.
> 

GV> Really … what about this section in http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/

3.2.  IGP-Prefix Segment, Prefix-SID

   An IGP-Prefix Segment is an IGP segment attached to an IGP prefix.
   An IGP-Prefix Segment is global (unless explicitly advertised
   otherwise) within the SR/IGP domain.

   The required IGP protocol extensions are defined in IGP SR extensions
   documents.

> 2) with global labels come applicability area being only SPRING based networks, please add this to the technology usability section
> 
> ​That is incorrect technically. The draft is equally applicable to basic L3VPNs to match on VPN label either as second in the stack or first (case of Inter-as option B at ASBRs). 
> 

GV> Yes indeed using the service label gives you telemetry capability. Hence why not simply use the RT trigger to push a label by flowspec. The description on how this would work is unclear and confusing.
It is the trigger for a lot of misunderstandings (where are the labels coming form, how is the stitching happening, how to check if the label pushed is going to the original destination , etc…) . It is to me totally with the current write-up.

>  
> 3) Traditional best path selection is used to find best NLRI, however a different to IGP label is pushed ... The draft does not describe measures to guaranty that the pushed label represents the same destination node.
> 
>  
> ​Sorry but this extension does not distribute labels to be pushed on the packets as the IGP or bottom label on the stack. ​It does however provide means to apply demux label for application layer (the example in the draft is EPE). I personnaly see nothing wrong with such approach.
> 

GV> again, why not use a VPN service label to achieve this? its the same result if each RT is unique and is announce by the correct egress device… nothing new is needed when using this
> 4) why is this solution better as using traditional flowspec redirect to VRF (with exact one route in VRF)? In this case telemetry for flowspec redirect can be done with existing technology ... Nothing new is required...
> 
> 
> ​That's comparing apples to oranges ... ​The vrf redirection is a local action. Imagine that packets have been redirected to local vrf. Now within such local VRF you have entered static route to send packets say to some collector or exit ASBR. 
> 

GV> It is not comparing apples with oranges. Redirection is local action, however technically the label pushed can be a service label which can be used for telemetry. This service label is announced by the remote egress device by attaching the RT for each particular telemetry instance … in that case you have the IGP label + flow telemetry service label. The service label can be used for telemetry… It is even better as in this case it is 100% certain that the flow ends up at the right router and has the right label attached to avoid looping etc…

Ciao,
G/

> But if you would like to further add a demux value which such collector or exit ASBR would use to switch packets to proper context this is where this extension can be used. 
> 
> ​Best,
> R.​
> 
> 
> Understanding the above considerationd i do not feel the current draft is ready for adoption.
> 
> Ciao,,
> G/
> 
> 
> 
> Sent using CloudMagic Email <https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.0.67&pv=6.0&source=email_footer_2>
> On Tue, Dec 01, 2015 at 11:16 AM, Wesley Eddy <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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/ <http://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/>
> 
> 
> 
> 
> It would be good in the draft to clarify the assumptions about global (or at least mutual) significance of the labels, but this is more about clearly describing its use and operation than any impact to the protocol spec.
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 1 Dec 2015 09:51:25 +0000

Support the adoption of this draft.

Xiaohu

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, November 24, 2015 7:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] WG Call for adoption on draft-liang-idr-bgp-flowspec-label-01 (11/24 to 12/8)

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: Robert Raszuk <[email-masked]>
Date: Tue, 1 Dec 2015 11:20:01 +0100

>
> GV> Really … what about this section in
> http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
>

​What you are quoting is a reference to IGP-Prefix Segment ​which is global
.... it is not reference to mpls "global label"

​Besides this is SPRING draft not an MPLS​ WG RFC.

GV> Yes indeed using the service label gives you telemetry capability.
> Hence why not simply use the RT trigger to push a label by flowspec. The
> description on how this would work is unclear and confusing.
>

​But who is saying that RT would not be used for import. RFC5575 is
explicit in stating that Route Target extended community can be attached to
FlowSpec routes for import.

​      ​
Propagation of this NLRI is controlled by matching Route Target
   extended communities associated with the BGP path advertisement with
   the VRF import policy, using the same mechanism as described in "BGP/

      MPLS IP VPNs" [RFC4364 <https://tools.ietf.org/html/rfc4364>] .​

​This spec is just adding new information which can be used after importing
to a VRF. ​

GV> again, why not use a VPN service label to achieve this? its the same
> result if each RT is unique and is announce by the correct egress device…
> nothing new is needed when using this
>

​You are mixing things I am afraid. "VPN service" is used to distribute
reachability. FlowSpec is used to distribute a set of defined filters for
such reachability.

Q: How do you encode match on port number in SAFI 128 ?

GV> It is not comparing apples with oranges. Redirection is local action,
> however technically the label pushed can be a service label which can be
> used for telemetry. This service label is announced by the remote egress
> device by attaching the RT for each particular telemetry instance … in that
> case you have the IGP label + flow telemetry service label. The service
> label can be used for telemetry… It is even better as in this case it is
> 100% certain that the flow ends up at the right router and has the right
> label attached to avoid looping etc…
>

​Same comments as above :)

Cheers,
R.

---

From: Gunter Van De Velde <[email-masked]>
Date: Tue, 1 Dec 2015 21:29:00 +0800

The mud is starting to become more clear… Currently my understanding of the draft is that proposal is pushing an additional service label aka a Telemetry Label. 
This telemetry label is label used to indicate that the packet matched a particular flowspec rule.

The operational behaviour is as follows:

at an SP ingress router which is implementing the flowspec rule and under the condition that the ingress packet matches the flowspec rule, then this label is pushed.

Example1: if the packet is just following Global routing table, then the packet will have an exterior IGP label L1 AND a label L2 to indicate that the packet was matched by this flowspec rule.
Assumption is that the egress router can correlate the L2 to be a telemetry service label. (How is that correlation being done exactly? In the draft i see mentioned that it is allocated by the 
egress PE, but then how can the Flowspec controller figure this out? )

Example2: If the ingress packet is received through a VPN, the the packet will have exterior IGP label L1, VPN service label L2 AND the label L3 to indicate the the packet was matched 
by the flowpsec rule. Assumption is again that the egress router can correlate L3 with being a Telemetry label.

A new question: 
* What would happen if PIC re-route would happen for multi-homed connections, how are the labels to be sync’d between egress PE’s?
* Where would the label be inserted in the label stack? as far as possible to the top of the label stack or more towards the bottom of the label stack? 

Please see inline for further thoughts:

> On 01 Dec 2015, at 18:20, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
> 
> GV> Really … what about this section in http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ <http://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/>
> 
> 
> ​What you are quoting is a reference to IGP-Prefix Segment ​which is global .... it is not reference to mpls "global label"
> 

GV> It describes a a global identifier for a prefix that gets correlated to a label that is used for this prefix in the MPLS realm. However, if the above operational description is correct, then it does not really matter too much as the relevance is between ingress and egress Router. However, if you want to have probes inside the network consuming this label and using it for Telemetry then the label needs to be unique in the network though for easiest operation.

> ​Besides this is SPRING draft not an MPLS​ WG RFC.

GV> so you say: not invented by MPLS WG and because it is not even a standard in MPLS we authors do not care? It deserves imo some text to explain that the label is either network unique or has only local significance. It should not be very hard to explain and makes it better document for the person reading the draft. 

> ​But who is saying that RT would not be used for import. RFC5575 is explicit in stating that Route Target extended community can be attached to FlowSpec routes for import. 
> 
> ​      ​Propagation of this NLRI is controlled by matching Route Target
> ​This spec is just adding new information which can be used after importing to a VRF. ​
> 

GV> I did not understand that its “a Telemetry Service Label”. Nevertheless, what i am proposing is that by overloading the VRF with Telemetry context, you have the same thing. No need to add a new label.

> ​You are mixing things I am afraid. "VPN service" is used to distribute reachability. FlowSpec is used to distribute a set of defined filters for such reachability. 
> 

GV> Good question actually… it made me think a little on how to overload the VRF with the Telemetry context. However, can it not be done?.

Lets take the following example: 
Closeby-End —— PE1 —— ISP network —— PE2 —— Far-end

On PE2 we have VPN11 which has all the Far-end routes and they will all be exported with RT1:1, and imports RT1:1, RT1:2, RT1:3 and RT1:4 towards PE1
In addition we have: 
  VPN12 which injects 0/0 and exports with RT1:2 to PE1
  VPN13 which injects 0/0 and exports with RT1:3 to PE1
  VPN14 which injects 0/0 and exports with RT1:4 to PE1
  ...

Lets assume we have three flowspec rules: FlowSpec1, FlowSpec2 and FlowSpec3

In this case FlowSpec1 for example can match on port numbers and as consequence may redirect matching traffic to VPN12 and hence all matched traffic will enjoy the service label for 0/0 in VPN12.
This provides context information that the packet is matched by Flowspec1, while still routed to the Far-end.
FlowSpec2 could match upon other parameters and then redirect to VPN13 and start using its correlated service label as Telemetry label.

This would be a way to overload the VPN service label with additional context for Telemetry. I know it is not very friendly and neither clean, but it can be done technically with existing technology.
No need for a new solution which can already be done with existing technologies.

> ​Same comments as above :)

GV> see above… Service label can be overloaded with context if need to be.

GV> btw, where i do see potential use for pushing a Label by using Flowspec is for Entropy-Label/ELI through Flowspec… that way a controller can use selective matching to manipulate load distribution trough the network. However this is different from the use-case described in this draft. Maybe draft can be extended for that purpose?

Ciao,
G/

---

From: Gunter Van De Velde <[email-masked]>
Date: Tue, 1 Dec 2015 21:30:02 +0800

> On 01 Dec 2015, at 21:29, Gunter Van De Velde <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Dec 2015 15:42:09 +0100

Gunter,

​..
>  service label aka a Telemetry Label. This telemetry label is label used
> to indicate that the packet matched a particular flowspec rule.
>

​Where did you took this "telemetry" word from :) ? Just curious .....

To it means something completely ​different then "service/application
label".

In other words I am yet to see a draft where there is decent proposal to
"measure" any value over a distance with a label. Specifically Flow Spec
does not do any telemetry if you are using such wording in the current IETF
definition (draft-ietf-dots-requirements).

Flowspec is just a tool to mitigate an attack already described by other
means. Similary flowspec is seen by some folks as a tool to push around
configuration and policy also defined somewhere else.

A new question:
> * What would happen if PIC re-route would happen for multi-homed
> connections, how are the labels to be sync’d between egress PE’s?
>

​VPN labels can be synced according ​to well known proposals from some
vendors. Hint:  search for "50 ms service restoration" or "seamless mpls
service".

> * Where would the label be inserted in the label stack? as far as possible
> to the top of the label stack or more towards the bottom of the label
> stack?
>

​It would be inserted where it is expected to be received by the
destination router.
​

> This would be a way to overload the VPN service label with additional
> context for Telemetry. I know it is not very friendly and neither clean,
> but it can be done technically with existing technology.

​How are you going to achieve that in practice ? Notice that VPN label is
allocated by PEs and FlowSpec label by collector device which for all
practical purposes is not a PE.

Proposing a dependency between SAFI 134 and SAFI 128 neither works nor is
technically feasible IMO here.

However this is different from the use-case described in this draft. Maybe
> draft can be extended for that purpose?
>

​The most successful ​drafts are those which are applied for use cases
never thought of by their original authors.

Best,
r.

---

From: Gunter Van De Velde <[email-masked]>
Date: Tue, 01 Dec 2015 23:02:31 +0800

Sent using CloudMagic Email
[https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.0.67&pv=6.0&source=email_footer_2] On Tue, Dec 01, 2015 at 10:42 PM, Robert Raszuk < [email-masked] [[email-masked]] > wrote:
Gunter,
.. service label aka a Telemetry Label. This telemetry label is label used to
indicate that the packet matched a particular flowspec rule.
Where did you took this "telemetry" word from :) ? Just curious .....
To it means something completely ​different then "service/application label".
In other words I am yet to see a draft where there is decent proposal to
"measure" any value over a distance with a label. Specifically Flow Spec does
not do any telemetry if you are using such wording in the current IETF
definition (draft-ietf-dots-requirements).

Flowspec is assigning in this proposal a label where the application is
measurement. The draft abstract read for example "this facilitates monitoring and traffic
   statistics for FlowSpec rules.

"

Flowspec is just a tool to mitigate an attack already described by other means.
Similary flowspec is seen by some folks as a tool to push around configuration
and policy also defined somewhere else.
A new question:
* What would happen if PIC re-route would happen for multi-homed connections,
how are the labels to be sync’d between egress PE’s?
VPN labels can be synced according ​to well known proposals from some vendors.
Hint: search for "50 ms service restoration" or "seamless mpls service".
In that case labels were assigned differently. I would like to see section to
discus around this un the document.

* Where would the label be inserted in the label stack? as far as possible to
the top of the label stack or more towards the bottom of the label stack?
It would be inserted where it is expected to be received by the destination
router.
And that is where exactly? Label stack depth is important... A few words would
help instead of forgetting about it.

This would be a way to overload the VPN service label with additional context
for Telemetry. I know it is not very friendly and neither clean, but it can be
done technically with existing technology. No need for a new solution which can already be done with existing
technologies.
How are you going to achieve that in practice ? Notice that VPN label is
allocated by PEs and FlowSpec label by collector device which for all practical
purposes is not a PE.

All i was saying is that it is technical possible. Btw, maybe the collector isn't PE but the attached router is one.

For flowspec there is no dependency at all. There is just redirection to a vpn
which happens to have some extra context.

However this is different from the use-case described in this draft. Maybe draft
can be extended for that purpose?
The most successful ​drafts are those which are applied for use cases never
thought of by their original authors.

Sure... But for the use-case proposed in current draft i see nothing new which
can not be done right now already.
G/

Best, r.

---

From: Lucy yong <[email-masked]>
Date: Tue, 1 Dec 2015 16:29:54 +0000

I support this adoption. This proposal allows a BGP router to disseminate a flowspec with a bound label and requires a node (BGP speaker) that installs the flowspec inserts the label on the flowspec packets prior to sending to the router, so that the router can do something to the packets with the label.

My understanding is that such label can be local allocated or global, it depends on the applications; the protocol in the draft supports both.  The rule is that a node must insert the label that is assigned by the next-hop BGP that is the best route for the node.

I agree that the draft needs some development to be ready for RFC. The WG adoption will facilitate the development within the WG.

Lucy

---

From: "Dan Ma (danma)" <[email-masked]>
Date: Tue, 1 Dec 2015 17:59:59 +0000

Yes, support.   Not aware about any IPR.

Thanks
Dan

On Tue, Nov 24, 2015 at 12:29 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
This begins a 2 week adoption call for draft-liang-idr-bgp-flowspec-label-01.txt  which can be found at:

Sue Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Dec 2015 11:07:44 -0500

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

At this time, I do not support the document for adoption.  As some of the
discussion in this thread is indicating, the use case isn't quite clear in
some circumstances.  This leaves me with operational and deployment
concerns.

I think once the document has been clarified, I would reconsider my stance.
(Magic 8 ball says, "Ask again later".)

-- Jeff