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

From: "Susan Hares" <[email-masked]>
Date: Mon, 21 Mar 2016 07:44:57 -0400

We welcome comments on this BGP flow specification match based on MPLS. 

Sue, Lucy, Qiandeng, and Jianjie

==============

A new version of I-D, draft-yong-idr-flowspec-mpls-match-00.txt
has been successfully submitted by Susan Hares and posted to the IETF repository.

Name:		draft-yong-idr-flowspec-mpls-match
Revision:	00
Title:		BGP Flow Specification Filter for MPLS Label
Document date:	2016-03-21
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-yong-idr-flowspec-mpls-match-00.txt
Status:         https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/
Htmlized:       https://tools.ietf.org/html/draft-yong-idr-flowspec-mpls-match-00

Abstract:
   This draft proposes BGP flow specification rules that are used to
   filter MPLS labeled packets.

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Mar 2016 18:42:18 -0400

Authors,

> 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.
'a' is ambiguous when both 'e' and 'a' are set.
'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.

pos - is this intended to match the magic reserved labels or do you mean
this is reserved for future use?

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.

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?

-- Jeff

---

From: Lucy yong <[email-masked]>
Date: Tue, 29 Mar 2016 21:56:00 +0000

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:[email-masked]] 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,

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/idr