headers
jai hari | 4 Aug 2003 20:03
Picon
Favicon

Route refresh/ capability

Hi,
  I have a list of basic questions in RFC 2918/3392. Please let me know if 
these have already been
  answered in the mail-archives.

1. Is an implementation allowed to support route refresh capability without 
supporting Multiprotocol
   capability?  RFC 2918 states "If a BGP speaker receives from its peer a 
ROUTE-REFRESH message with
   the <AFI, SAFI> that the speaker didn't advertise to the peer ". What is 
the peer advertising if
   it did not support Multiprotocol capability?

2. RFC 3392 states: "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,"
   What about the case where the local speaker receives a capability it does 
not understand/support.?
   Should it send a notification - unsupported capability?

3. Are capabilities encoded as a single open optional parameter or multiple 
open optional parameters?
   Does the standard require it to be either way?

4. Is restarting hold timer for the session accepted upon receiving a route 
refresh request?

5. What should be the action ( ignore? ) if route refresh request is 
received from a peer that did
(Continue reading)

Permalink | Reply | 5 comments |
headers
John G. Scudder | 4 Aug 2003 20:39
Picon
Favicon

Re: Route refresh/ capability

At 6:03 PM +0000 8/4/03, jai hari wrote:
>2. RFC 3392 states: "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,"
>   What about the case where the local speaker receives a capability 
>it does not understand/support.?
>   Should it send a notification - unsupported capability?

No, it should not.

--John

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Ankur Goyal | 4 Aug 2003 20:44

RE: Route refresh/ capability

> 3. Are capabilities encoded as a single open optional parameter or multiple
> open optional parameters?
> Does the standard require it to be either way?


The standard allows it to be either way.  


--Ankur
Permalink | Reply | 0 comments |
headers
naresh paliwal | 5 Aug 2003 06:55
Favicon

Re: Re: Route refresh/ capability

Yeah!! john is right, unless the mib variable strict capabily 
match is set.. Otherwise notification is needed..

-Naresh

On Tue, 05 Aug 2003 John G. Scudder wrote :
>At 6:03 PM +0000 8/4/03, jai hari wrote:
>>2. RFC 3392 states: "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,"
>>   What about the case where the local speaker receives a 
>>capability it does not understand/support.?
>>   Should it send a notification - unsupported capability?
>
>No, it should not.
>
>--John
>
>_______________________________________________
>Idr mailing list
>Idr <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/idr

___________________________________________________
Download the hottest & happening ringtones here!
OR SMS: Top tone to 7333
Click here now: 
http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl
(Continue reading)

Permalink | Reply | 0 comments |
headers
naresh paliwal | 5 Aug 2003 07:10
Favicon

Re: Route refresh/ capability

>1. Is an implementation allowed to support route refresh 
>capability without supporting Multiprotocol
>   capability?  RFC 2918 states "If a BGP speaker receives from 
>its peer a ROUTE-REFRESH message with
>   the <AFI, SAFI> that the speaker didn't advertise to the peer 
>". What is the peer advertising if
>   it did not support Multiprotocol capability?

Need not, As <IPv4, Unicast> is supported anyway..

>4. Is restarting hold timer for the session accepted upon 
>receiving a route refresh request?

It make sense to restart Hold timer and keep alive timer.

>5. What should be the action ( ignore? ) if route refresh request 
>is received from a peer that did
>  not advertise this capability at all?

It an error <message header error, bad message type>

>6. Is Open message optional parameter length really required to 
>parse the message? ( Is header length
>  not sufficient? )

But then header length need to be redefined for open message, as 
message length.. Doesnt make sense to me.

-Naresh
___________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manav Bhatia | 5 Aug 2003 15:03

Re: Route refresh/ capability

Jai,

> 7. How should errors in capability length field  that does not agree with
> header length ( or optional parameter length ) be handled? (What is the
> notification code? Is it open messag errorcode with subcode
unspecified? )

You send a NOTIFICATION message with the Cease (6) Error Code.

>
> 8. Does the standard care how to handle a route refresh request while one
is
> already pending? (Can we
>   just abort and restart the previous adj-rib-out update? )

No.

~Manav

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 3 comments |
headers
Internet-Drafts | 6 Aug 2003 13:47
Picon
Favicon

I-D ACTION:draft-ietf-idr-cease-subcode-03.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		: Subcodes for BGP Cease Notification Message
	Author(s)	: E. Chen, V. Gillet
	Filename	: draft-ietf-idr-cease-subcode-03.txt
	Pages		: 4
	Date		: 2003-8-5
	
This document defines several subcodes for the BGP Cease NOTIFICATION
message that would provide more information to aid network operators
in co-relating network events and diagnosing BGP peering issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-idr-cease-subcode-03.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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Susan Hares | 8 Aug 2003 15:59

FW: idr minutes


IETF 57 IDR Minutes
Chairs: Yakov Rekhter, Sue Hares

ID Document Status (chairs)
------------------
- Base Spec done! Will post -21 after IETF.
- See slides

Avoid BGP Best Path Transition From one External to Another
	      draft-chen-bgp-avoid-transition-00.txt
-----------------------------------------------------------
-  BGP identifier used in last phases of BGP routes selection
-  Appear random
-  Subject to change
-  Reduces stability
-  Proposed solution: Don't eliminate either path due to BGP ID during path
selection
-      Exception: AS Confederations; parallel sessions
- Advantages: stability, reduce iBGP oscillation

- Request to adopt as WG draft, but WG is in closed status until base doc is
approved

Advertising Equal Cost Multipath Routes in BGP
              draft-bhatia-ecmp-routes-in-bgp-00
-------------------------------------------------
- Route reflector only advertises route that it installs
- May not be optimal for all RR clients or external peers
- May lead to route oscillation
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manav Bhatia | 13 Aug 2003 13:51

Re: FW: idr minutes

Checking mails after some gap ..

> CHEN: How is this different from last presentation
> Bhatia: Don't need to change encoding

I thought he was talking of Alvaro's draft and hence i said "No need to
change the encoding".

This proposal is very different from the previous presentation. In the
previous there isnt any way to advertise multiple paths. The central idea
being that the tie breaking should never reach the point where the RIDs are
compared.

> CHEN: Advertising best external route also solves oscillation problem.
> Without changing spec.
> Marques: Draft should be named "How to advertise multiple paths in BGP".
> Look at Alvero's draft.
> Yakov: Also look at how MP-BGP addresses this

The ECMP_NEXT_HOP attribute already has the AFI field. Just need to add a
SAFI field.

All subsequent UPDATEs with the ECMP_NEXT_HOP attribute carrying the <AFI,
SAFI> will not be treated as implicit withdrawals and will instead be
appended to the existing RIB. There is thus no special treatment required
for MP-BGP.

Regards,
Manav
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 15 Aug 2003 18:50
Picon
Favicon

I-D ACTION:draft-ietf-idr-dynamic-cap-04.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		: Dynamic Capability for BGP-4
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-ietf-idr-dynamic-cap-04.txt
	Pages		: 6
	Date		: 2003-8-15
	
This document defines a new BGP capability termed 'Dynamic
Capability', which would allow the dynamic update of capabilities
over an established BGP session. This capability would facilitate
non-disruptive capability changes by BGP speakers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-idr-dynamic-cap-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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane