Re: [Idr] FW: New Version Notification for draft-yong-idr-flowspec-mpls-match-00.txt

Hi Jeff,

Thank you very much for the comment and suggestion. The draft is for the work initiative and need to work in the WG to specify them properly. Please see inline below.

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Monday, March 28, 2016 5:42 PM
To: Susan Hares
Cc: 'idr@ietf. org'
Subject: Re: [Idr] FW: New Version Notification for draft-yong-idr-flowspec-mpls-match-00.txt

Authors,

On Mon, Mar 21, 2016 at 07:44:57AM -0400, Susan Hares wrote:
> We welcome comments on this BGP flow specification match based on MPLS. 

[Note that I'm intentionally avoiding the "which rev of flowspec does this go in" discussion.]

For your operator actions:
'e' needs clarification when there is more than one of these set.
[[Lucy]] OK. this bit indicates the last <pair> on the list. 
'a' is ambiguous when both 'e' and 'a' are set.
[[Lucy]] When both 'e' and 'a' are set, means that both the label in previous pair and the label value in last pair need to be matched.
'i' may be problematic to implement on some vendors and thus may lead to interoperability issues.  This is due to many vendors implementing their firewalling as a ingress-only operation.
[[Lucy]] understand. if we have use cases for both, i.e., matching before and after label stack operation, protocol  need to support it. If not, no need to be complex.

pos - is this intended to match the magic reserved labels or do you mean this is reserved for future use?
[[Lucy]] this is another one for WG thinking a bit. I am not sure we need special indication for magic reserved labels.
Pos:00 with a reserved label value serves the purpose too. Maybe valuable to fast filter for magic reserved label?

I think one of the cases I would have hoped to see is basically an indexed operation.  For example, for purposes of matching specific target tunnel endpoints, matching the second from top label (which might *not* be the bottom label) is sometimes interesting, especially for LDP over RSVP.
Similarly, it helps spring applications.
[[Lucy]] Good suggestion. We can add this in next version. However, the index may be easy to prune an operation error as pop/push operation along the path. It needs to be specific.

It seems a little unusual that you've chosen to separate the fate of matching ToS bits from the label itself and are only examining the top label's bits.  Any particular reason?
[[Lucy]] Initial thought is that they mean differently, FlowSpec may want to monitor traffic per label(s) or per QoS class. If true, this way will is operation simpler. Like to hear the community feedback on this.

Thanks,
Lucy 

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr