Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Sun, 05 Aug 2007 10:46:41 -0700

Folks,

Please keep in mind that silence counts as a lack of interest, not
as a sign of support.

Yakov.
------- Forwarded Message

Date:    Fri, 27 Jul 2007 08:01:14 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document

Folks,

IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt 
as an IDR WG document (see attached).

Comments are greatly appreciated. The deadline for comments is
August 10, 2007.

Yakov.
- ------- Forwarded Message

Date:    Thu, 26 Jul 2007 12:33:27 -0600
From:    Danny McPherson <[email-masked]>
To:      Hares Susan <[email-masked]>, Yakov Rekhter <[email-masked]>
cc:      Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt 

Susan/Yakov,
As discussed in the meeting today, could you please ask
the WG about this becoming a WG item?

- - -danny

Begin forwarded message:

> From: [email-masked]
> Date: July 8, 2007 4:15:02 PM MDT
> To: [email-masked]
> Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Dissemination of flow specification rules
> 	Author(s)	: P. Marques, et al.
> 	Filename	: draft-marques-idr-flow-spec-04.txt
> 	Pages		: 25
> 	Date		: 2007-7-8
> 	
> This document defines a new BGP NLRI encoding format that can be used
>    to distribute traffic flow specifications.  This allows the routing
>    system to propagate information regarding more-specific  
> components of
>    the traffic aggregate defined by an IP destination prefix.
>
>    Additionally it defines two applications of that encoding format.
>    One that can be used to automate inter-domain coordination of  
> traffic
>    filtering, such as what is required in order to mitigate
>    (distributed) denial of service attacks.  And a second  
> application to
>    traffic filtering in the context of a BGP/MPLS VPN service.
>
>    The information is carried via the Border Gateway Protocol (BGP),
>    thereby reusing protocol algorithms, operational experience and
>    administrative processes such as inter-provider peering agreements.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-04.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-marques-idr-flow-spec-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-marques-idr-flow-spec-04.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

- ------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Paul Jakma <[email-masked]>
Date: Sat, 11 Aug 2007 19:20:00 +0100 (IST)

> Please keep in mind that silence counts as a lack of interest, not

I'd support this being adopted as an informational document. I think 
it's well-understood that BGP is /the/ tool for distributing packet 
filtering information...

That said, if it were to be considered as a standard, some serious 
thought needs to be given to whether it is appropriate to stuff 
flow-filters into UPDATE:

- The rationale that NLRIs are opaque to a point, and that BGP
    filtering mechanisms are quite agnostic to NLRI composition seems
    questionable.

- There's no conceptual sense to installing flow-specs into a RIB -
    no selection is made between flows, the NLRIs are not
    hierarchical; simply put a lot of the language in 4271 no longer
    applies to flow-specs.

    (E.g. flow-specs to describe, potentially, IPv6,etc.. flows would
     use AFI=1???)

It might be more natural to use a different message type. Nothing 
would prevent re-use of attributes and mechanisms specified already 
for UPDATE. This would allow the authors to design a nice clean, 
extensible message; optimum re-use, minimum baggage.

I think such an approach would be simpler in every conceivable way..

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You have mail.

---

From: "Pedro R. Marques" <[email-masked]>
Date: Sat, 11 Aug 2007 11:41:55 -0700

>    no selection is made between flows,

Section 5 of the document states otherwise:

    Flow specifications received from a BGP peer and which are accepted
    in the respective Adj-RIB-In are used as input to the route selection
    process.  Although the forwarding attributes of two routes for the
    same Flow Specification prefix may be the same, BGP is still required
    to perform its path selection algorithm in order to select the
    correct set of attributes to advertise.

Do you believe that the text is not clear enough in this respect ?

   Pedro.

---

From: Paul Jakma <[email-masked]>
Date: Sat, 11 Aug 2007 20:35:03 +0100 (IST)

> Do you believe that the text is not clear enough in this respect ?

It's clear, but that section is proving exactly my point. ;)

That section makes it clear we're dealing with routing meta-data, not 
distinct routing information: It quite clearly describes that we're 
talking about data that derives meaning from routes...

To move to a less abstract nit with the details of this draft: All 
the NLRI tuple types are optional, but validation seems to require a 
destination address. So shouldn't destination be a required tuple for 
the NLRI? How is a flow-spec without destination validated? It seems 
it can't be, in which it's pointless to allow such NLRIs (until some 
future draft specifies how..).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
telnet: Unable to connect to remote host: Connection refused

---

From: "Pedro R. Marques" <[email-masked]>
Date: Sat, 11 Aug 2007 13:00:35 -0700

Paul Jakma wrote:

I apologize but i'm unable to follow the distinction between meta-data 
and routing and thus refrain from commenting.

> 
> To move to a less abstract nit with the details of this draft: All the 
> NLRI tuple types are optional, but validation seems to require a 
> the NLRI? How is a flow-spec without destination validated?

The automatic validation procedure rejects a route unless a destination 
address is present and matches unicast routing. Imho the document is 
clear about this.

> It seems it 
> can't be, in which it's pointless to allow such NLRIs (until some future 
> draft specifies how..).

Existing implementations allow the administrator to assert that flow 
routes matching particular criteria are to be accepted. This is the most 
common deployment mode and requires no explicit standardization.

   Pedro.

---

From: Paul Jakma <[email-masked]>
Date: Sun, 12 Aug 2007 00:30:12 +0100 (IST)

On Sat, 11 Aug 2007, Pedro R. Marques wrote:

> I apologize but i'm unable to follow the distinction between meta-data and 
> routing and thus refrain from commenting.

I'll restate the point in another email, in a fashion more directly 
related to the draft.

> The automatic validation procedure rejects a route unless a 
> destination address is present and matches unicast routing. Imho 
> the document is clear about this.

Agreed.

> Existing implementations allow the administrator to assert that 
> flow routes matching particular criteria are to be accepted. This 
> is the most common deployment mode and requires no explicit 
> standardization.

Right, but that is at odds with the text of the draft. It's a nit 
with the text as it stands..

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Most public domain software is free, at least at first glance.

---

From: Paul Jakma <[email-masked]>
Date: Sun, 12 Aug 2007 00:39:05 +0100 (IST)

On Sat, 11 Aug 2007, Paul Jakma wrote:

> To move to a less abstract nit with the details of this draft:

Another one:

- what happens when the route (real route) which caused a flow-spec
   to validate correctly is removed?

It really seems to me these flow-specs are inherently tied to the RIB
for some /normal/ afi/safi, in the current text...

I.e. given the validation process mandated[1], the flow-specs are 
/derived/ from routes[2]. Indeed, if (rather than inventing some 
artificial SAFI) you index the flow-specs using the existing RIB, 
upon whose entries these flow-specs depend, then we can note:

- The 'protocol' discriminator in the flow-spec NRLI is redundant..
- The 'destination' discriminator in the flow-spec is redundant..

Anyway, that's something to consider once the scope of this 
validation procedure is clarified.

1. And that validation procedure is a 'must' in the text:

   "A flow specification NLRI must be validated ... if and only if:"

2. The flows describe something that must be consequent to the route
    (without the route, the flow-spec is not valid, by this draft),
    hence the flow is meta-data of the route, to clarify a previous
    point.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
QOTD:
 	I've heard about civil Engineers, but I've never met one.

---

From: "Pedro R. Marques" <[email-masked]>
Date: Sat, 11 Aug 2007 16:55:57 -0700

>   to validate correctly is removed?

The document states that the flow route is valid iff and only if certain 
conditions are met. If those conditions no longer hold true the 
validation state has to transition to false.

> for some /normal/ afi/safi, in the current text...

That is correct.

> /derived/ from routes[2].

You cannot derive flow routes from unicast routes.

> Indeed, if (rather than inventing some 
> artificial SAFI) you index the flow-specs using the existing RIB, upon 
> whose entries these flow-specs depend, then we can note:
> 

Protocol matches against the "protocol" field in the IP packet. Can you 
please tell us how is that redundant ?

> - The 'destination' discriminator in the flow-spec is redundant..

Please explain how that is the case. For it to be redundant one assumes 
that you can derive it from information already present in the system. 
I'd like to see an example of how that is the case.

> 
> Anyway, that's something to consider once the scope of this validation 
> procedure is clarified.
> 

I fail to see how flow routes describe information about unicast routes.

   Pedro.

---

From: Paul Jakma <[email-masked]>
Date: Sun, 12 Aug 2007 01:38:01 +0100 (IST)

On Sat, 11 Aug 2007, Pedro R. Marques wrote:

> The document states that the flow route is valid iff and only if 
> certain conditions are met. If those conditions no longer hold true 
> the validation state has to transition to false.

Right. So don't you need to state that you are adding to section 9 of 
4271 then?

Also, I refer back to my question about why the destination 
discriminator can be optional, if it is required for validation..

These two are nits in the draft that you can easily clarify regarding 
the current state of deployed flow-spec, I think, no?

Below is a conceptual discussion, nothing to do with what is 
deployed:

>> I.e. given the validation process mandated[1], the flow-specs are /derived/ 
>> from routes[2].
>

I'll try again:

  "The proposition that some flow-spec is valid or not is derived from
   routes (of related AFI,SAFI)."

Given that (and it's given in the draft!), it seems conceptually odd 
to take *all* flow-specs, pertaining to flows of potentially various 
different AFIs,SAFIs and stuff them all together into a new RIB.

> please tell us how is that redundant ?

If I've had to use the IPv4 RIB to validate the flow-spec, then the 
flow-spec must apply to packets only of that protocol.

> Please explain how that is the case. For it to be redundant one 
> assumes that you can derive it from information already present in 
> the system. I'd like to see an example of how that is the case.

I'm obviously mistaken there - sorry ;).

> I fail to see how flow routes describe information about unicast routes.

Right. They relate to them though - the draft specifies that.

It doesn't make conceptual sense to try think of the aggregate 
flow-information as composing a distinct, seperate and indepent RIB. 
It doesn't make sense to even think of them as belonging to a RIB 
(they don't describe routes - we seem agreed on that).

It just be simpler to not use UPDATE, rather than creating a 
franken-AFI/SAFI. To just have a flow-spec message type that can just 
fan-out to its own validator (re-using UPDATE attributes is still 
trivial).

I dont see the point of trying to overload UPDATE with stuff that 
looks *nothing* like routes.. (a point we seem agreed on).

Anyway...

Notwithstanding abstract questions, there do seem to more immediate 
questions, see top of mail.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
QOTD:
 	"I used to go to UCLA, but then my Dad got a job."

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Aug 2007 22:10:56 -0700

Hi Paul,

> Right. So don't you need to state that you are adding to section 9 of

I don't think we need to. Notice that 9.1.2 talks about BGP route 
selection and we are not adding/changing those.

What we are describing is an add-on for the purpose of particular 
application ... flow-spec.

In other words I can easily see a case where flow-spec route will be 
valid and propagated by BGP (for example by RR) yet in the same time not 
valid by flow-spec rules - the case where one uses different RRs for 
IPv4 unicast and for flow-spec reflection.

> the current state of deployed flow-spec, I think, no?

Correct. The destination is optional for two reasons ... for BGP 
4271/9.1.2 section it is not required and for flow-spec it is optional 
when operator disables the auto-validation feature.

In fact one deployment scenario is to block/rate-limit/monitor network 
wide some specific ports/applications. Mandating to have destination 
prefix of any length would make the above application much harder.

> different AFIs,SAFIs and stuff them all together into a new RIB.

But that is clearly not the case .. even in the draft. You have separate 
RIB per each flow-spec SAFI (example 133/134).

> flow-spec must apply to packets only of that protocol.

That is exactly the case.

Cheers,
R.

---

From: Paul Jakma <[email-masked]>
Date: Sun, 12 Aug 2007 10:40:58 +0100 (IST)

> selection and we are not adding/changing those.

Uhm, the document lays out a rationale for how flow-specs are no 
different to other routes distributed through BGP, to a point:

"   BGP itself treats the NLRI as an opaque key to an entry in its
     databases.  Entries that are placed in the Loc-RIB are then
     associated with a given set of semantics which is application
     dependent.  This is consistent with existing BGP applications."

The existing text in 4271:9 barely applies to this SAFI though.

Essentially, it'd be nice, for potential implementors, if the draft 
could make it clear which bits of 4271 do and which don't apply to 
this SAFI (given the document in one place tries to explain that much 
of 4271 *is* applicable ;) ).

> What we are describing is an add-on for the purpose of particular application 
> ... flow-spec.

Right, we're in violent agreement they're not routes.

> In other words I can easily see a case where flow-spec route will 
> be valid and propagated by BGP (for example by RR) yet in the same 
> time not valid by flow-spec rules - the case where one uses 
> different RRs for IPv4 unicast and for flow-spec reflection.

Ok.

> 4271/9.1.2 section it is not required and for flow-spec it is 
> optional when operator disables the auto-validation feature.

Right.

But an implementation which allows the auto-validation feature to be 
disabled would no longer conform with this draft, as validation is a 
'must'.

Either the draft needs to say validation is optional, or else the 
destination discriminator needs to become mandatory.

> In fact one deployment scenario is to block/rate-limit/monitor 
> network wide some specific ports/applications. Mandating to have 
> destination prefix of any length would make the above application 
> much harder.

Neat and understood (all along). I'm trying to point out the draft 
is missing some text.. ;)

> But that is clearly not the case .. even in the draft. You have 
> separate RIB per each flow-spec SAFI (example 133/134).

Well, yes. Each artificial SAFI in the draft has its own SAFI and 

>> different AFIs,SAFIs and stuff them all together into a new RIB.

E.g. 1/133 (unicast flow-specs), could contain flow-specs for 
protocols IP and IPv6 - and they both go into one 'FlowIB', sorry RIB 
;). I.e. it's pretty clear you end up with one RIB, which may contain 
information relating to packets of /multiple/ AFIs.

Further, this RIB requires reference to one or more other RIBs to be 
validated, which jars with this text in section 2:

     "se RIBs should be treated independently from each other in order
      to assure non-interference between distinct applications."

;)

A lot of the philosophical BGP stuff in section 2 should just be 
removed IMHO.

> That is exactly the case.

So the protocol discriminator is misnamed; it's not a discriminator 
for matching packets, it's the key to which unicast RIB is to be used 
for validation.

That presumes of course that validation via RIB is required, which 
the draft and deployed reality apparently are in disagreement about 
;).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
In Devon, Connecticut, it is unlawful to walk backwards after sunset.

---

From: Paul Jakma <[email-masked]>
Date: Sun, 12 Aug 2007 10:47:58 +0100 (IST)

On Sun, 12 Aug 2007, Paul Jakma wrote:

> this SAFI (given the document in one place tries to explain that 
> much of 4271 *is* applicable ;) ).

Oh, this is why it'd just be nicer to have it a seperate message 
type. No need to worry about what extant bits of BGP (and code) 
do and don't implicitely apply to flow-specs.

(While still allowing explicit re-use of existing BGP features 
obviously..).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Feature was not beta tested

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Mon, 13 Aug 2007 10:25:43 -0700

> looks *nothing* like routes.. (a point we seem agreed on).

  While I am personally not against using BGP for a variety of applications..
  I think the point you raise is very important. It seems to me that over
  time we have used the basic message structure of BGP and fitted applications
  to them even when all we might have wanted is the distribution semantics
  of BGP. In this case we have constructed an NLRI that is a long list of
  components and atleast _to me_ is a cery creative interpretation of an
  UPDATE message. What about the attributes? There is a statement that all
  standard BGP policy mechanisms should apply as usual, in the draft but
  based on the limited amount of time I have spent on this draft, I cannot
  see that many of the attributes would even apply here. Till date that has
  not been asked for when new AFI/SAFIs are brought in..

  Rgds,
  Chandra.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Aug 2007 13:21:00 -0700

Chandra,

>   not been asked for when new AFI/SAFIs are brought in..

You are asking the same question again to which I have already replied 
on the 10th of Aug. Was there anything in my reply not clear which would 
require further explanation ?

I think I explained well the reasons for flow-spec rules to be placed in 
the MP_REACH NLRIs.

If on the other hand you would like to discuss if new drafts fit the 
sematics of BGP UPDATE msg could you start a new thread and bring some 
arguments which would justify draft-pmohapat-idr-info-safi-02.txt to fit 
semantics of BGP UPDATE msg ? I did spend sufficient amount of time on 
this draft and see no relation of it's proposed NLRI format to routing 
information.

Thx,
R.

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Mon, 13 Aug 2007 13:27:12 -0700

> semantics of BGP UPDATE msg ? I did spend sufficient amount of time on 

  I was not specifically pointing to the flowspec idea as the only one where we are
  crossing a boundary (I do not even know if there is one)... my comments was 
  that generally that in IDR I have
  not seen that as a community we ask that question when new AFi/SAFI requests
  are brought in. I agree with you that such a question might apply to other
  AFI/SAFI also. Paul's point did resonate with my thinking and my response
  was in the context of his point.

  Rgds,
  Chandra.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Aug 2007 13:34:23 -0700

Hi Chandra,

And that is exactly why I only suggested you should start a new thread 
on that topic and let this one be focused on discussion related to 
flow-spec only.

Cheers,
R.