headers
John G. Scudder | 1 Mar 14:40
Favicon

Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00

FYI.  We plan to present this at the upcoming IDR meeting.

URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: March 1, 2009 8:35:33 AM GMT-05:00
> To: jgs <at> juniper.net
> Cc: enkechen <at> cisco.com
> Subject: New Version Notification for  draft-scudder-idr-optional- 
> transitive-00
>
>
> A new version of I-D, draft-scudder-idr-optional-transitive-00.txt  
> has been successfuly submitted by John Scudder and posted to the  
> IETF repository.
>
> Filename:	 draft-scudder-idr-optional-transitive
> Revision:	 00
> Title:		 Error Handling for Optional Transitive BGP Attributes
> Creation_date:	 2009-03-01
> WG ID:		 Independent Submission
> Number_of_pages: 6
>
> Abstract:
> According to the base BGP specification, a BGP speaker that receives
> an UPDATE message containing a malformed attribute is required to
(Continue reading)

Permalink | Reply | 28 comments |
headers
Thomas Narten | 2 Mar 18:40
Picon
Favicon

Re: IPR related to the flow-spec I-D

Yakov Rekhter <yakov <at> juniper.net> writes:

> I'd like to explain a bit of the confusion surrounding the IPR
> disclosure issue. On 12/23/2008 Juniper disclosed IPR on the flow-spec
> draft (https://datatracker.ietf.org/ipr/1052/), but it contained
> an incorrect "terms" section.

Actually, I believe there is slightly more to it than this. IIRC, the
December disclosure only listed a single patent application. The
revised one lists one patent (issued) plus 5 patent applications (no
information available AFAICT). So the disclosure has been expanded to
include significantly (?) more possible IPR compared with the original
disclosure.

Correct?

That said, the revised terms are IMO an improvement. Thanks.

> The disclosure was removed at Juniper's request and resubmitted on
> 02/09/2009 with the proper "terms" section. Unfortunately, Juniper's
> legal team released a number of IPR disclosures on or about
> 12/23/2008 and had to remove and correct all of them so, the sudden
> flurry of activity may have been worrying to some. You may have seen
> many corrected IPR disclosures on the IETF's IPR webpage
> (https://datatracker.ietf.org/ipr/about/) and more are to
> come. Juniper intended no harm or malice by these actions and
> Juniper is working to make certain that disclosures are made in a
> more timely manner.

Regardng timing. The flow-spec document lists 6 authors, four of them
(Continue reading)

Permalink | Reply | 6 comments |
headers
Danny McPherson | 3 Mar 03:26

Re: IPR related to the flow-spec I-D


On Mar 2, 2009, at 10:40 AM, Thomas Narten wrote:

> Can the Contributers to this document please clarify the history and
> their role in it better w.r.t the IPR disclosures? I'm particularly
> concerned about the timing of the filing of the IPR and its subsequent
> disclosure. It seems rather odd that an ID that has been under
> discussion within the IETF for some 5 1/2 years would be subject of an
> IPR disclosure at such a late date (only after IETF LC starts) in the
> process.

I had no knowledge of IPR regarding flow-spec until
the disclosure was filed with the IETF.  Nor did Jared,
I believe.

-danny
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Danny McPherson | 3 Mar 09:12

Re: Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00


On Mar 1, 2009, at 6:40 AM, John G. Scudder wrote:

> FYI.  We plan to present this at the upcoming IDR meeting.
>
> URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt

Some comments on the draft...

-
I'm not sure I like the recommended behavior in S 2
where we're treating malformed updates "as though all
contained prefixes had been withdrawn".  I'd strongly
prefer that in ALL cases the update be discarded.
Making assumptions and providing rules for how to
selectively handle mal-formed updates seems much like
something you yourself would caution us against.  I'd
much prefer a 'discard and log' requirement.

-
I could see how this text is S 2. might not be the case,
if varying implementations handle a given update in
different ways:

"This is likewise the case if an optional transitive
attribute is received whose Partial bit is not set --
this is because the detected error can be imputed to
the direct peer."

No other comments, I think this is a useful document.
(Continue reading)

Permalink | Reply | 21 comments |
headers
Robert Raszuk | 3 Mar 10:37

Re: IPR related to the flow-spec I-D

Hi Thomas,

Since the original draft's publication date June 2003 (well even earlier 
as I started to discuss this idea with Pedro Marques around beg of 2003 
if not earlier) I was fully aware about Juniper's authors filing the 
patent application for this work. There was no mystery of any sort made 
reg this filing.

That was and still is the common industry practice in any vendor for any 
novel work which is going to be publicly presented. AFAIK you can safely 
assume that vast majority of IETF drafts have patents filed behind. The 
fact that some lawyers did not disclosed it on time is regrettable, but 
should not be a point of any discussion in IDR WG.

As I recommended already before if such disclosures are so important 
IETF should add a mandatory section of any draft template or mandatory 
field on the draft submission page to list them or explicitly state 
"none". Having the draft publishing and IPR disclosures submission 
taking totally independent paths as it is today is just a clear receipt 
for more cases like this one to happen.

Header of the original authors/co-authors:

Network Working Group                                      Pedro Marques
INTERNET DRAFT                                             Nischal Sheth
Expiration Date: December 2003                     Juniper Networks, Inc
                                                            Robert Raszuk
                                                       Cisco Systems, Inc
                                                              Jared Mauch
                                                                NTT/Verio
(Continue reading)

Permalink | Reply | 4 comments |
headers
Robert Raszuk | 3 Mar 11:11

Re: Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00

Hi Danny,

 > contained prefixes had been withdrawn".  I'd strongly
 > prefer that in ALL cases the update be discarded.

Wouldn't making "silent" update discard lead to stale BGP paths sitting 
in the network as long as the session they were received on is up ? I am 
  thinking about implicit/explicit withdraws in fact in both ebgp and 
ibgp cases.

Do we making in this draft an implicit assumption that transitive 
attribute malformation must always happen day one and not after the 
original advertisement have already left the originator ?

I think the current text at least suggest that if withdraw of NLRIs is 
possible when we drop the update let's dispatch it.

I personally don't like the "if" part. If we make a protocol decision 
optimized for "most common" scenarios and not "all cases" IMHO we are 
already starting to cut the branch we are sitting on.

    "While lamentable, this
    issue is expected to be rare in practice, and more importantly is
    seen as less problematic than the session-reset behavior it
    replaces."

I would actually propose to drop the update _only_ if withdraw of NLRIs 
it contains can be generated. If not continue today's behavior to drop 
the session. Having even if "rear in practice" black wholes is quite 
scary if some folks are already looking at using IP to control for
(Continue reading)

Permalink | Reply | 18 comments |
headers
John G. Scudder | 3 Mar 14:40
Favicon

Re: Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00

On Mar 3, 2009, at 3:12 AM, Danny McPherson wrote:
> I'm not sure I like the recommended behavior in S 2
> where we're treating malformed updates "as though all
> contained prefixes had been withdrawn".  I'd strongly
> prefer that in ALL cases the update be discarded.
> Making assumptions and providing rules for how to
> selectively handle mal-formed updates seems much like
> something you yourself would caution us against.  I'd
> much prefer a 'discard and log' requirement.

The example below should refresh your memory of why "discard" doesn't  
fly.  "Treat as withdraw" is basically the closest *safe* version of  
"discard".

--John

> From: "John G. Scudder" <jgs <at> juniper.net>
> Date: December 15, 2008 2:34:34 PM GMT-05:00
> To: Danny McPherson <danny <at> tcb.net>
> Cc: Jeffrey Haas <jhaas <at> pfrc.org>, cayle.spandon <at> gmail.com, Enke  
> Chen <enkechen <at> cisco.com>, quaizar.vohra <at> gmail.com, skh <at> nexthop.com,  
> Inter-Domain Routing List <idr <at> ietf.org>, Yakov Rekhter <yakov <at> juniper.net 
> >, Tony Li <tony.li <at> tony.li>, Quaizar Vohra <qv <at> juniper.net>
> Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes
>
> On Dec 15, 2008, at 2:21 PM, Danny McPherson wrote:
>> After thinking about this for a few minutes, I can't currently
>> come up with any configuration where a forwarding loop would occur
>> as a result of just dropping the update (because the "translation"
>> occurs on ingress to an AS), so discarding the update is likely
(Continue reading)

Permalink | Reply | 0 comments |
headers
John G. Scudder | 3 Mar 14:50
Favicon

Re: Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00

On Mar 3, 2009, at 3:12 AM, Danny McPherson wrote:
> I could see how this text is S 2. might not be the case,
> if varying implementations handle a given update in
> different ways:
>
> "This is likewise the case if an optional transitive
> attribute is received whose Partial bit is not set --
> this is because the detected error can be imputed to
> the direct peer."

Can you be more specific about this?  It seems to me that the behavior  
for setting the Partial bit is fully specified, so all compliant &  
correct implementations should behave more or less the same in that  
respect.

Since the relevant corollary in this case is that if the Partial bit  
is not set we know that the direct peer recognized the path attribute  
(else it would have set the Partial bit), I guess we can focus on what  
the consequences are if that is NOT done.  Case 1 is when the direct  
peer doesn't set Partial even though it doesn't recognize the  
attribute.  In that case we would falsely "blame" the direct peer for  
the detected malformation and reset the session.  I think this is OK  
insofar as the direct peer *does* have a bug in its path attribute  
handling in this scenario, although not the one we think it does.   
Case 2 is when the direct peer recognizes the attribute but sets  
Partial anyway.  In that case we would mistakenly give the direct peer  
a free pass instead of "blaming" it, and would follow the treat-as- 
withdraw behavior instead of resetting the session.  This isn't ideal,  
but we already think treat-as-withdraw is OK as the general-case error- 
handling behavior -- session reset is an optimization.  So I think
(Continue reading)

Permalink | Reply | 0 comments |
headers
John G. Scudder | 3 Mar 15:00
Favicon

Re: Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00

Hi Robert,

On Mar 3, 2009, at 5:11 AM, Robert Raszuk wrote:
> Do we making in this draft an implicit assumption that transitive  
> attribute malformation must always happen day one and not after the  
> original advertisement have already left the originator ?

No, the draft applies equally regardless of where the malformation is  
introduced.

> I think the current text at least suggest that if withdraw of NLRIs  
> is possible when we drop the update let's dispatch it.

Sorry, didn't follow the above.

> Two additional points to the claim that dropping the session is  
> worst thing ...

I'd be interested in feedback from the WG regarding the question of  
withdrawing the routes (what the draft proposes) vs. dropping the  
session (current behavior).  Especially feedback from network operators.

--John
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 17 comments |
headers
Jeffrey Haas | 3 Mar 15:54

Withdrawing request for early assignment of mib-2 OIDs

After further discussion with our MIB doctor and the working group
chairs, I'd like to withdraw my request for an early allocation for
mib-2 OIDs for the BGP MIBv2 MIBs.  We would like to get the MIBs a
little further along in the standardization process before we take that
step.

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

Gmane