Subject: [Idr] draft-chen-bgp-prefix-orf-07.txt as an IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Mon, 19 Jul 2004 08:42:23 -0700

Folks,

We received a request to accept draft-chen-bgp-prefix-orf-07.txt
as an IDR WG document (see e-mail to the list on Jul 14, 2004). 

It would be greatly appreciated if folks would read the document and 
comment on it to the IDR mailing list. In other words, we need 
"yes, looks good" or "should fix this and that", not just silence.

I would suggest to have August 2 as the deadline for comments. But
if folks feel that it is not enough time (as we have the IETF in
two weeks), we could extend the deadline.

Yakov.

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

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Mon, 19 Jul 2004 14:20:54 -0400

>two weeks), we could extend the deadline.

Could I get a procedural clarification?  I've always assumed that 
sooner or later, the different ORF proposals (prefix, AS path, 
community) would be harmonized. Do they each have to get to IDR I-D 
before this can happen?

---

From: Enke Chen <[email-masked]>
Date: Mon, 19 Jul 2004 12:00:14 -0700

Hi, folks:

Yes, I think that we should adopt the draft as an IDR document.

 1) The Prefix ORF is already in the IDR Charter:

     May 04  Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG
             as a Proposed Standard

     In order to reach the milestone, it would be necessary to make the
     draft an IDR document.

 2) The spec is mature and has been implmented and deployed for several years.

Thanks.  -- Enke

> Message-Id: <[email-masked]>
> To: [email-masked]
> Date: Mon, 19 Jul 2004 08:42:23 -0700
> From: Yakov Rekhter <[email-masked]>
> Subject: [Idr] draft-chen-bgp-prefix-orf-07.txt as an IDR WG document
> 
> Folks,
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 20 Jul 2004 12:38:15 -0700

Yes, looks good.

R.

 > Yakov Rekhter wrote:

---

From: Danny McPherson <[email-masked]>
Date: Wed, 21 Jul 2004 23:26:14 -0600

I also support the draft and would like to see it
become a WG document.  I agree with Howard (and
think I mentioned it here over a year ago) that we
should try to converge the different ORF drafts before
we progress them within the WG.

-danny

---

From: Enke Chen <[email-masked]>
Date: Thu, 22 Jul 2004 11:41:32 -0700

Hi, Danny:

> From: Danny McPherson <[email-masked]>
> Subject: Re: [Idr] draft-chen-bgp-prefix-orf-07.txt as an IDR WG document
> Date: Wed, 21 Jul 2004 23:26:14 -0600
> To: idr <[email-masked]>
> 
> become a WG document.

Thanks for voice your opinion.

> I agree with Howard (and think I mentioned it here over a year ago)
> that we should try to converge the different ORF drafts before

It is not clear to me what you meant by "converge", and what issue we
try to address.

If it means "combine" the documents, I do not see benefits but drawbacks.

  - Except for the common properties described in the base ORF spec,
    each ORF type has type-specific properties (e.g., encoding and
    matching).

  - The implementation of one ORF type is independent of the
    implementation of another. It is possible that some vendor might
    choose to implement one, and not another (based on customer
    requirements).

  - Having separate drafts would allow us to progress each ORF type
    independently (when one is implemented and ready, similary to
    the BGP capability).

  - It might not be practicle to exhaustively combine the ORF types
    as more types are being proposed (e.g., max prefix ORF).

  - Authors of each ORF type should be held accountable for that
    type, not more and not less :-)

Regarding Howard's comment on "harmonized", it seems to me that the
ORF types are already "harmonized" as the base ORF spec has already
specified procedures for dealing with multiple ORF types.

-- Enke

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Jul 2004 12:47:51 -0700

I must admit that I fully agree with Enke.

It seems just impossible to combine all "ORF drafts" whatever this term 
means simply due to the fact that ORF-type has been designed as an 
extensible indicator to the purpose of given ORF message.

The best analogy would be to request that all BGP attributes should be 
combined into one draft/rfc when you really can't tell what attribute 
may be needed tomorrow.

Besides even today there seems to be already too many proposals for ORF 
message use to fit into one readable doc (not to mention author list :). 
To list them here: prefix ORF, prefix limit ORF, AS-PATH ORF, ext 
community ORF etc ...

So my vote is to keep the base spec with historically first ORF 
application as is and incrementally and separately be able to add new 
functionality with new ORF-types.

Cheers,
R.

 > Enke Chen wrote:

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 22 Jul 2004 16:34:54 -0400

Seems reasonable to make draft-chen-bgp-prefix-orf-07.txt a WG document.

I also agree with Enke's recent comments regarding why not to merge 
the various ORF-type documents.  The only benefit that it appears 
would be realized is that you'd have a one-stop shop for all the ORF 
types (that existed as of the publication of the merged doc).  That 
doesn't seem compelling.

--John

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 22 Jul 2004 19:12:34 -0400

>If it means "combine" the documents, I do not see benefits but drawbacks.

I meant combine.  While I recognize there can be good reasons to have 
vendor flexibility, especially in the case of BGP, the overall 
Internet benefits from interoperability.

My perspective is not always from that of a vendor. Indeed, it 
unfortunately has to include certain of the less clueful of users.

To clarify, I would want to see at least the equivalent of an overall 
applicability document or other overview that discusses the tradeoffs 
of the various types.  I don't have a problem with separate detailed 
implementation specifications, but the proliferation of options, in 
my experience, is causing confusion among at least some users.

>     each ORF type has type-specific properties (e.g., encoding and

That is relevant to implementers. A reasonable customer perspective 
is to have the various alternatives available in one place so the 
most appropriate one can be chosen.

>     choose to implement one, and not another (based on customer

Anything is possible. I would not regard this as a good thing, in the 
interest of interoperability.  In this specific case, I could see a 
vendor perhaps not implementing all at once due to resources, but I 
really find it hard to imagine a customer, who has accepted the basic 
logic of ORF, wanting to be limited to one or another type.  We are 
not talking here of exotic types. Every type involved is in routine 
use in BGP configurations where ORF is not used.

>     independently (when one is implemented and ready, similary to

Once operators, and especially end enterprises, start using ORF to a 
significant degree, I need to be convinced that it is a good thing if 
a series of functionally related capabilities shows up in random 
order.

>     as more types are being proposed (e.g., max prefix ORF).

Then there can be versions. There could be an applicability document.

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 22 Jul 2004 19:19:05 -0400

At 12:47 PM -0700 7/22/04, Robert Raszuk wrote:
>It seems just impossible to combine all "ORF drafts" whatever this 
>term means simply due to the fact that ORF-type has been designed as 
>an extensible indicator to the purpose of given ORF message.
>
>The best analogy would be to request that all BGP attributes should 
>be combined into one draft/rfc when you really can't tell what 
>attribute may be needed tomorrow.
>
>Besides even today there seems to be already too many proposals for 
>ORF message use to fit into one readable doc (not to mention author 
>list :). To list them here: prefix ORF, prefix limit ORF, AS-PATH 
>ORF, ext community ORF etc ...

If these were all meant to be Experimental, that would be one thing. 
The idea that so many types are evolving that they cannot go into one 
readable document cries for an application of Occam's Razor.

It's not that any of these are radically new BGP capabilities. Most 
exist in standards, and most are implemented in non-ORF BGP. Now, I 
always tell of the time that I was giving a seminar at NASA, took a 
break, and listened to the instructor in the next room, who was 
discussing the Shuttle propulsion system.  I could have sworn I heard 
him say "Hey, come on. This is rocket science, not BGP."

Is it rocket science to stop and ask "what are the operational 
benefits of each of these additional types", and record some of that 
discussion?  Alternatively, the question could be posed "of all 
functions that are used, either vendor-specific or standards-based, 
in eBGP route selection, which should NOT be available in an ORF 
method, and why or why not?"

---

From: Danny McPherson <[email-masked]>
Date: Thu, 22 Jul 2004 19:23:02 -0600

>     each ORF type has type-specific properties (e.g., encoding and

Of course.

>     choose to implement one, and not another (based on customer

Of course.

>     as more types are being proposed (e.g., max prefix ORF).

I agree.  I only suggest doing so for proposals to date that the
WG believes make sense.  E.g., I'm not sure about value of max-
prefix ORF Type, so I do understand your concern.  However,
I see no reason prefix & attribute-based ORF Types should be in
a slew of independent drafts from the start.

>     type, not more and not less :-)

Blah..  It's going to be a WG document..  This, i.e., Authors, is
the heart of the issue.

> specified procedures for dealing with multiple ORF types.

The base specification includes prefix ORF, why not other ORF Types that
the WG believes should be included?  Or should we take prefix out
as well and have a truly base specification so as to not prolong 
progress
in the WG (I'm kidding).

It just seems the many ORF Type drafts should be coupled into a
single specification while we still have the opportunity, if the WG 
believes
they have merit.  Else there'll be even more documents folks will need
to go trudging through to find the bits their interested in.

Of course, I really don't feel strongly enough about this to continue
supporting my position (i.e., I'm busy :-), but it just seems a bit
silly to me.

I would like to see this work progress in the WG, regardless.  And
it is in the charter, so..

-danny

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 22 Jul 2004 19:32:58 -0700

Yes, I think this should become a WG doc.

On the topic of merging the various ORF type docs, if there
was a clear consensus or need, I am sure the original authors
would have added them all in the base spec. Since they did not
and we are seeing the individual submissions, I would leave it
that way so that only the ones required will survive....

-
Chandra Appanna.

---

From: Enke Chen <[email-masked]>
Date: Thu, 22 Jul 2004 22:11:13 -0700

> Message-Id: <[email-masked]>
> Content-Transfer-Encoding: 7bit
> Date: Thu, 22 Jul 2004 19:23:02 -0600
> To: idr <[email-masked]>
> 

[snip]

> progress in the WG (I'm kidding).

You must refer to a very early version (from years ago) which defined a
prefix ORF that had no similarity with the current prefix ORF, and was
removed years ago.  The current ORF base spec includes only two very
simple ORF types (community ORF and ext-community ORF).

Regards,  -- Enke

---

From: Danny McPherson <[email-masked]>
Date: Thu, 22 Jul 2004 23:20:48 -0600

On Jul 22, 2004, at 11:11 PM, Enke Chen wrote:
>
> You must refer to a very early version

Ahh, yes, my mistake.

I'd forgot about draft-ietf-idr-route-filter-*

danny

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Jul 2004 10:03:05 -0400

> Yes, I think this should become a WG doc.

I also think it should become a WG document (but still need to do
a quick read-through of the current draft).

> would have added them all in the base spec.

To nitpick a little bit, ORFs, like extended communities, seem to 
strongly have come out of certain vendor's needs for certain
technology to solve a specific problem.  The fact that they were
adaptable to a more generic tool speaks well of the authors of
the specifications.  However, I think that a more generic solution
would have done us well in each case.  

ORFs are extremely coarse policy.  Extended communities have already
been criticized for not being flexibile enough.  Yet each solves
the problems for their original problem space well enough.  Rough
consensus and all that. :-)

> Since they did not

I'd generally agree. 

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Jul 2004 10:26:23 -0400

> a slew of independent drafts from the start.

One of the problems of combining the specifications (which I don't think
we should do) is that it ties them all together in the standards
process.

As it stands, in order to implement the base specification, it's
somewhat implied that you're going to implement the community
and extended community ORFs.  Thankfully this isn't outright
required in the base document (if you didn't care to implement
them), but this isn't clear enough that our respective organizations
wont have a little jousting to do with comformance test vendors
that so often make our lives... interesting.

-- 
Jeff Haas 
NextHop Technologies