headers
Internet-Drafts | 2 Apr 19:30
Picon
Favicon

I-D Action:draft-ietf-idr-flow-spec-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Dissemination of flow specification rules
	Author(s)       : P. Roque Marques, et al.
	Filename        : draft-ietf-idr-flow-spec-01.txt
	Pages           : 25
	Date            : 2008-04-02

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-ietf-idr-flow-spec-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Muller | 8 Apr 15:28
Favicon

Re: SendNOTIFICATIONwithoutOPEN

If I am reading the specification correctly the  
SendNOTIFICATIONwithoutOPEN is for communicating error states so  
unless the initial peering has occurred and/or this configuration is  
setup on both peers the SendNOTIFICATIONwithoutOPEN would fail. Or am  
I reading the specification wrong?

Sean Muller
seangmuller <at> runbox.com
214-250-3988 Cell
"Do or do not... there is no try.” Yoda

On Mar 31, 2008, at 3:23 AM, Jithu Arun Sreedhar wrote:
> Hi
>
> By the definition of SendNOTIFICATIONwithoutOPEN, it allows a peer to
> send a NOTIFICATION without first sending an OPEN message. But how do
> you convey this to the peer dynamically. Statically if you know so
> then the working of the attribute can be explained, but for dynamic
> configurations, for example an unconfigured peer, how do you let the
> BGP peer know that you are expecting a NOTIFICATION without an OPEN in
> case of an OPEN error.
>
> Jithu Arun Sreedhar.
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pierre Francois | 16 Apr 15:33
Picon
Favicon

I-D Action:draft-francois-bgp-gshut-00.txt

Hi all,

Please find below a draft that tries to address the requirements draft for the 
graceful shutdown of BGP sessions.

We would appreciate your feedback on this first attempt.

Regards,
Pierre.

-------- Original Message --------
Subject: I-D Action:draft-francois-bgp-gshut-00.txt
Date: Sat, 15 Mar 2008 13:45:01 -0700 (PDT)
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           : Graceful BGP session shutdown
    Author(s)       : P. Francois, et al.
    Filename        : draft-francois-bgp-gshut-00.txt
    Pages           : 15
    Date            : 2008-03-15

This draft describes operational procedures aimed at reducing the
amount of traffic lost during planned maintenances of routers,
involving the shutdown of BGP peering sessions.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
sundeep.mudgal | 22 Apr 17:35
Picon

BGP: Vendor Specific Capabilities


Hi,

        Could you please confirm whether vendor-specific capabilities should be ignored or responded to with the unsupported capability message?

Thanks,
Sandeep Mudgal 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 7 comments |
headers
Kalpesh Zinjuwadia | 22 Apr 19:23
Favicon

Re: BGP: Vendor Specific Capabilities

Implementation can choose either way. RFC3392 states that “the decision is local to the speaker”.

 

Thanks,

Kalpesh

 

From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of sundeep.mudgal <at> nokia.com
Sent: Tuesday, April 22, 2008 8:36 AM
To: idr <at> ietf.org
Subject: [Idr] BGP: Vendor Specific Capabilities

 

 

Hi,

        Could you please confirm whether vendor-specific capabilities should be ignored or responded to with the unsupported capability message?

Thanks,
Sandeep Mudgal 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Neil Matthew | 22 Apr 19:48

Re: BGP: Vendor Specific Capabilities

Hi

Given the wording of the question I'd like to stress the "local to the 
speaker" part. A peer should not close a connection just because it 
doesn't recognize a capability. It's up to the speaker to determine 
whether support for the particular capability is vital for the 
connection to continue.

Cheers

Neil

Kalpesh Zinjuwadia wrote:
>
> Implementation can choose either way. RFC3392 states that “the 
> decision is local to the speaker”.
>
> Thanks,
>
> Kalpesh
>
> *From:* idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] *On Behalf 
> Of *sundeep.mudgal <at> nokia.com
> *Sent:* Tuesday, April 22, 2008 8:36 AM
> *To:* idr <at> ietf.org
> *Subject:* [Idr] BGP: Vendor Specific Capabilities
>
> Hi,
>
> Could you please confirm whether vendor-specific capabilities should 
> be ignored or responded to with the unsupported capability message?
>
> Thanks,
> Sandeep Mudgal
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>   

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
John G. Scudder | 22 Apr 19:59
Picon
Gravatar

Re: BGP: Vendor Specific Capabilities

It should be ignored.  Per RFC 3392, the unsupported capability  
message is a way to complain if your peer doesn't support a capability  
that you insist on having support for.  An example would be if the  
peer doesn't support MP-BGP and you are trying to establish a v6  
peering.  Here is the pertinent text from RFC 3392:

"If a BGP speaker that supports a certain capability determines that  
its peer doesn't support this capability, the speaker MAY send a  
NOTIFICATION message to the peer, and terminate peering (see Section  
"Extensions to Error Handling" for more details). The Error Subcode in  
the message is set to Unsupported Capability. The message SHOULD  
contain the capability (capabilities) that causes the speaker to send  
the message. The decision to send the message and terminate peering is  
local to the speaker. If terminated, such peering SHOULD NOT be re- 
established automatically."

I apologize for the confusing name of the notification message.   
Probably something like "Required Capability Missing" would have been  
better. :-(

Correct behavior with respect to any unknown capability from your peer  
(whether vendor-specific or otherwise) is generally to ignore it.

--John

On Apr 22, 2008, at 11:35 AM, <sundeep.mudgal <at> nokia.com> <sundeep.mudgal <at> nokia.com 
 > wrote:

>
> Hi,
>
>         Could you please confirm whether vendor-specific  
> capabilities should be ignored or responded to with the unsupported  
> capability message?
>
> Thanks,
> Sandeep Mudgal
>
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 4 comments |
headers
sundeep.mudgal | 22 Apr 20:39
Picon

Re: BGP: Vendor Specific Capabilities

So when you say "ignore", does it mean that peer continues with the connection or drop the connection without sending any notification?


-----Original Message-----
From: ext John G. Scudder [mailto:jgs <at> bgp.nu]
Sent: Tue 4/22/2008 12:59 PM
To: Mudgal Sundeep (Nokia-S&S/MtView)
Cc: idr <at> ietf.org
Subject: Re: [Idr] BGP:  Vendor Specific Capabilities

It should be ignored.  Per RFC 3392, the unsupported capability 
message is a way to complain if your peer doesn't support a capability 
that you insist on having support for.  An example would be if the 
peer doesn't support MP-BGP and you are trying to establish a v6 
peering.  Here is the pertinent text from RFC 3392:

"If a BGP speaker that supports a certain capability determines that 
its peer doesn't support this capability, the speaker MAY send a 
NOTIFICATION message to the peer, and terminate peering (see Section 
"Extensions to Error Handling" for more details). The Error Subcode in 
the message is set to Unsupported Capability. The message SHOULD 
contain the capability (capabilities) that causes the speaker to send 
the message. The decision to send the message and terminate peering is 
local to the speaker. If terminated, such peering SHOULD NOT be re-
established automatically."

I apologize for the confusing name of the notification message.  
Probably something like "Required Capability Missing" would have been 
better. :-(

Correct behavior with respect to any unknown capability from your peer 
(whether vendor-specific or otherwise) is generally to ignore it.

--John

On Apr 22, 2008, at 11:35 AM, <sundeep.mudgal <at> nokia.com> <sundeep.mudgal <at> nokia.com
 > wrote:

>
> Hi,
>
>         Could you please confirm whether vendor-specific 
> capabilities should be ignored or responded to with the unsupported 
> capability message?
>
> Thanks,
> Sandeep Mudgal
>
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 3 comments |
headers
John G. Scudder | 22 Apr 22:25
Picon
Gravatar

Re: BGP: Vendor Specific Capabilities

Continue the connection.  In general one can think of the semantics of  
a BGP capability as being "I am able to do X" rather than "I insist on  
doing X".  If a pair of peers exchanges X, then that capability will  
typically be used.  If the peers do not exchange X, then it won't be.   
So, if your peer sends you X, and you don't support X, there's no  
problem.  You simply won't send X, so the peer won't attempt to use X  
on that peering.

--John

On Apr 22, 2008, at 2:39 PM, sundeep.mudgal <at> nokia.com wrote:

> So when you say "ignore", does it mean that peer continues with the  
> connection or drop the connection without sending any notification?
>
>
> -----Original Message-----
> From: ext John G. Scudder [mailto:jgs <at> bgp.nu]
> Sent: Tue 4/22/2008 12:59 PM
> To: Mudgal Sundeep (Nokia-S&S/MtView)
> Cc: idr <at> ietf.org
> Subject: Re: [Idr] BGP:  Vendor Specific Capabilities
>
> It should be ignored.  Per RFC 3392, the unsupported capability
> message is a way to complain if your peer doesn't support a capability
> that you insist on having support for.  An example would be if the
> peer doesn't support MP-BGP and you are trying to establish a v6
> peering.  Here is the pertinent text from RFC 3392:
>
> "If a BGP speaker that supports a certain capability determines that
> its peer doesn't support this capability, the speaker MAY send a
> NOTIFICATION message to the peer, and terminate peering (see Section
> "Extensions to Error Handling" for more details). The Error Subcode in
> the message is set to Unsupported Capability. The message SHOULD
> contain the capability (capabilities) that causes the speaker to send
> the message. The decision to send the message and terminate peering is
> local to the speaker. If terminated, such peering SHOULD NOT be re-
> established automatically."
>
> I apologize for the confusing name of the notification message.
> Probably something like "Required Capability Missing" would have been
> better. :-(
>
> Correct behavior with respect to any unknown capability from your peer
> (whether vendor-specific or otherwise) is generally to ignore it.
>
> --John
>
> On Apr 22, 2008, at 11:35 AM, <sundeep.mudgal <at> nokia.com> <sundeep.mudgal <at> nokia.com
>  > wrote:
>
> >
> > Hi,
> >
> >         Could you please confirm whether vendor-specific
> > capabilities should be ignored or responded to with the unsupported
> > capability message?
> >
> > Thanks,
> > Sandeep Mudgal
> >
> > _______________________________________________
> > Idr mailing list
> > Idr <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>
>

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 2 comments |
headers
John G. Scudder | 29 Apr 20:51
Picon
Gravatar

Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-00

Folks,

I've done some minor updates to the Capabilities Advertisement  
specification to address confusion about the "Unsupported Capability"  
NOTIFICATION message:

	Appendix B.  Comparison with RFC 3392
	
	   In addition to minor editorial changes, this document also clarifies
	   the use of the Unsupported Optional Parameter NOTIFICATION message,
	   and updates references to the base BGP-4 specification [RFC4271] and
	   security analysis [RFC4272].

The draft is at http://www.ietf.org/internet-drafts/draft-scudder-idr-rfc3392-bis-00.txt 
.

Comments welcome.  One thing that occurred to me was to rename  
"Unsupported Capability" to "Required Capability Missing", however  
that might do more harm than good by renaming an existing code point,  
so I didn't.

I'd like to propose this as a WG item (if indeed such a request is  
even required for an update to an existing WG document?).

Thanks,

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: April 29, 2008 2:41:21 PM GMT-04:00
> To: jgs <at> juniper.net
> Cc: rchandra <at> sonoasystems.com
> Subject: New Version Notification for draft-scudder-idr-rfc3392-bis-00
>
>
> A new version of I-D, draft-scudder-idr-rfc3392-bis-00.txt has been  
> successfuly submitted by John Scudder and posted to the IETF  
> repository.
>
> Filename:	 draft-scudder-idr-rfc3392-bis
> Revision:	 00
> Title:		 Capabilities Advertisement with BGP-4
> Creation_date:	 2008-04-29
> WG ID:		 Independent Submission
> Number_of_pages: 7
>
> Abstract:
> This document defines an Optional Parameter, called Capabilities,
> that is expected to facilitate the introduction of new capabilities
> in the Border Gateway Protocol (BGP) by providing graceful capability
> advertisement without requiring that BGP peering be terminated.  This
> document obsoletes RFC 3392.
>
>
>
> The IETF Secretariat.
>
>

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

Gmane