headers
Enke Chen | 2 Feb 2009 20:16
Picon
Favicon

[Fwd: I-D Action:draft-chen-rfc4893bis-01.txt]

Hi, folks:

The revised version includes the following changes from the -00.txt version:

   o The Error Handling section has been enhanced, with the error conditions
      for the new attributes spelled out.

   o Several "SHOULD NOT" are changed to "MUST NOT".

The diff is attached.

Thanks.   -- Enke

-------- Original Message --------
Subject: 	I-D Action:draft-chen-rfc4893bis-01.txt
Date: 	Mon, 2 Feb 2009 11:00:01 -0800 (PST)
From: 	Internet-Drafts <at> ietf.org
Reply-To: 	internet-drafts <at> ietf.org
To: 	i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : BGP Support for Four-octet AS Number Space
	Author(s)       : Q. Vohra, E. Chen
	Filename        : draft-chen-rfc4893bis-01.txt
	Pages           : 11
	Date            : 2009-02-02

Currently the Autonomous System (AS) number is encoded as a two-octet
entity in BGP. This document describes extensions to BGP to carry the
(Continue reading)

Permalink | Reply | 7 comments |
headers
IETF Secretariat | 3 Feb 2009 23:19
Picon
Favicon

Posting of IPR Disclosure

Dear Pedro Roque Marques, Danny McPherson, Nischal Sheth, Robert Raszuk, Barry Greene, Jared Mauch:

An IPR disclosure that pertains to your Internet-Draft entitled "Dissemination
of flow specification rules" (draft-ietf-idr-flow-spec) was submitted to the
IETF Secretariat on 2009-02-03 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR
disclosure is "Test Company 's Statement about IPR related to
draft-ietf-idr-flow-spec-05."

The IETF Secretariat

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Rob Shakir | 4 Feb 2009 12:33

Re: [Fwd: I-D Action:draft-chen-rfc4893bis-01.txt]

Enke,

Please see comments in-line to this diff.

> *** draft-chen-rfc4893bis-00.txt	Fri Jan 23 16:09:47 2009
> --- draft-chen-rfc4893bis-01.txt	Mon Feb  2 09:34:53 2009
> ***************
> *** 147,158 ****
>      To prevent the possible propagation of confederation path segments
>      outside of a confederation, the path segment types AS_CONFED_SEQUENCE
>      and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH
> !    attribute.  A NEW BGP speaker SHOULD NOT send these path segment
> !    types in the AS4_PATH attribute of an UPDATE message.  A NEW BGP
> !    speaker that receives these path segment types in the AS4_PATH
> !    attribute of an UPDATE message MUST discard these path segments,
> !    adjust the relevant attribute fields accordingly, and continue
> !    processing the UPDATE message.
>   
>      Similarly, this document defines a new aggregator attribute called
>      AS4_AGGREGATOR, which is optional transitive.  The AS4_AGGREGATOR
> --- 147,153 ----
>      To prevent the possible propagation of confederation path segments
>      outside of a confederation, the path segment types AS_CONFED_SEQUENCE
>      and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH
> !    attribute, and MUST NOT be carried in an UPDATE message.
>   
>      Similarly, this document defines a new aggregator attribute called
>      AS4_AGGREGATOR, which is optional transitive.  The AS4_AGGREGATOR
> ***************
(Continue reading)

Permalink | Reply | 6 comments |
headers
John Leslie | 4 Feb 2009 15:54
Favicon

Re: [Fwd: I-D Action:draft-chen-rfc4893bis-01.txt]

Rob Shakir <rjs <at> eng.gxn.net> wrote:
> 
>> 6. Error Handling
>>...
> 
> One error handling approach after we have discarded this attribute is
> stating in this RFC that any AS_TRANS that is observed in AS_PATH is
> assumed to be our own AS, unless we are able to replace it with data
> from AS4_PATH.

   This is actually two different cases:

1) we have an ASN > 65535, so this indeed might _be_ a loop;

2) we don't have an ASN > 65535, but we don't trust other ASs to perform
   this loop-prevention algorithm.

   For either of these, treating AS_TRANS as matching our ASN is the only
sure loop-prevention method.

> As someone commented to me off-list, loops are very destructive, and
> we should try to avoid them at almost any cost --

   If a routing loop actually happens, packets must travel the loop until
TTL is exhausted. TTL, alas, is set to 255 fairly often...

> if we assume AS_TRANS is us , then we don't 'punish' prefixes that are
> propagated with invalid data to us, but we do take measures to ensure
> that we are not causing a loop.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Jakma | 9 Feb 2009 19:21

Re: [Fwd: I-D Action:draft-chen-rfc4893bis-01.txt]

On Wed, 4 Feb 2009, Rob Shakir wrote:

> One error handling approach after we have discarded this attribute 
> is stating in this RFC that any AS_TRANS that is observed in 
> AS_PATH is assumed to be our own AS, unless we are able to replace 
> it with data from AS4_PATH. As someone commented to me off-list, 
> loops are very destructive, and we should try to avoid them at 
> almost any cost -- if we assume AS_TRANS is us , then we don't 
> 'punish' prefixes that are propagated with invalid data to us, but 
> we do take measures to ensure that we are not causing a loop.

This was suggested already. However it seems there is no need for 
this as, on any cycle, there should be at least one OLD speaker that 
will see its own, non-AS_TRANS, ASN and stop the loop. (See, e.g., 
emails from John Scudder).

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Kilroe hic erat!
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Yakov Rekhter | 11 Feb 2009 10:38
Favicon

Posting of IPR Disclosure for draft-ietf-idr-flow-spec

Folks,

Given that the draft just recently went through WG and IETF LC, if
folks have a concern, they should voice it asap.

Yakov.
------- Forwarded Message

Date:    Tue, 10 Feb 2009 17:12:54 -0800
From:    IETF Secretariat <ietf-ipr <at> ietf.org>
To:      roque <at> juniper.net, danny <at> arbor.net, nsheth <at> juniper.net, raszuk <at> juniper
	  .net,
	 bgreene <at> juniper.net, jared <at> puck.nether.net
cc:      rcallon <at> juniper.net, dward <at> cisco.com, idr <at> ietf.org, shares <at> ghs.com,
	 yakov <at> juniper.net, ipr-announce <at> ietf.org
Subject: Posting of IPR Disclosure

Dear Pedro Roque Marques, Danny McPherson, Nischal Sheth, Robert Raszuk, Barry 
Greene, Jared Mauch:

An IPR disclosure that pertains to your Internet-Draft entitled "Dissemination
of flow specification rules" (draft-ietf-idr-flow-spec) was submitted to the
IETF Secretariat on 2009-02-09 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR
disclosure is "Juniper's Statement of IPR related to
draft-ietf-idr-flow-spec-03."

The IETF Secretariat
(Continue reading)

Permalink | Reply | 10 comments |
headers
Thomas Narten | 12 Feb 2009 14:58
Picon
Favicon

Re: Posting of IPR Disclosure for draft-ietf-idr-flow-spec

FWIW, I believe that this document cannot and should not be advanced
unless the WG explicitly goes on record as stating that even with the
recent IPR disclosure, they still want to publish as a PS.

Silence cannot be interpreted as approval.

Thomas
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 4 comments |
headers
John Leslie | 12 Feb 2009 15:30
Favicon

Re: Posting of IPR Disclosure for draft-ietf-idr-flow-spec

Thomas Narten <narten <at> us.ibm.com> wrote:
> 
> FWIW, I believe that this document cannot and should not be advanced
> unless the WG explicitly goes on record as stating that even with the
> recent IPR disclosure, they still want to publish as a PS.

   I wouldn't demand quite that much, but I must urge the IESG not to
approve it _today_.

   The IPR disclosure clearly indicates that royalties might me charged;
and I am unable to find the patent application on the patent office site.

> Silence cannot be interpreted as approval.

   I agree. We have typically been dominated by corporations that will
not find RAND to be a problem, but there are at least two "free"
implementations of BGP in use that would be unable to pay royalties.

   If the WG chooses to say that the benefit exceeds that expense,
we need to say so clearly and publicly.

--
John Leslie <john <at> jlc.net>
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 3 comments |
headers
Joel M. Halpern | 12 Feb 2009 15:56

Re: Posting of IPR Disclosure for draft-ietf-idr-flow-spec

THE WG should probably look at this.
But it is hard to know whether this is worse than typical.  And it does 
not appear to be a matter of "expense."

The terms Juniper states are:
1) If you sue them, they reserve the right to sue you over infringing 
this patent
2) If there is something patented that is not "necessary for compliance 
with the standard" then they reserve the right to assert / license / 
control that.

Based on this, the question is not one of expense, but one of applicability.

Point 1 is clearly not a a problem or cost for the free community, and 
is a widely accepted condition in the commercial community.  We have 
accepted many standards track documents with defensive patent claims on 
them.

Point 2 is where the applicability issue comes in.  I have seen lawyers 
argue that as long as there is some context way of implementing the spec 
that can be implemented without the claim they are asserting, then the 
claim is not "necessary for compliance with the specification.  In that 
case, the reservation is very dangerous.
Conversely, it is fairly reasonable for a company to say that if you as 
a commercial implementor are doing something way beyond what the spec 
describes, and their patent describes that, then they can come after 
you.  That is what the game is about.  (I say "fairly reasonable" to 
stay out of the protracted argument about what corporate patent policies 
should be.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jari Arkko | 12 Feb 2009 16:10

Re: Posting of IPR Disclosure for draft-ietf-idr-flow-spec

The normal process is that the WG considers all aspects, technical and 
IPR, and makes a decision that they want to proceed.

 From my personal perspective the license conditions appear quite 
reasonable, should be OK even from open source point of view. But there 
is one word that troubled me a bit. Can we get anyone from Juniper to 
clarify whether "standard adopted by IETF" implies a standards track 
RFC, and NOT only full Standard (which might never be reached)?

But in any case, particularly since the IPR declarations came in so 
late, I think it would be best if the WG made an official decision (new 
WGLC) about this issue. I believe there are a few technical discusses 
from the IESG review today, so you could handle that in parallel.

Jari

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 4 comments |

Gmane