Subject: [Idr] Route refresh/ capability

From: "jai hari" <[email-masked]>
Date: Mon, 04 Aug 2003 18:03:41 +0000

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
  not advertise this capability at all?

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

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? )

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? )

Thanks,
-Jaihari

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

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

---

From: "Ankur Goyal" <[email-masked]>
Date: Mon, 4 Aug 2003 11:44:40 -0700

> Does the standard require it to be either way?

The standard allows it to be either way.  

--Ankur

v���X��X���k��_��!��l��0�X���+����Y���b�ا~��v

---

From: "Ankur Goyal" <[email-masked]>
Date: Mon, 4 Aug 2003 11:44:40 -0700

--Ankur

---

From: "naresh paliwal" <[email-masked]>
Date: 5 Aug 2003 04:55:16 -0000

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
>>   What about the case where the local speaker receives a 
>>capability it does not understand/support.?
>No, it should not.
>--John

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

---

From: "naresh paliwal" <[email-masked]>
Date: 5 Aug 2003 04:55:16 -0000

-Naresh

---

From: "naresh paliwal" <[email-masked]>
Date: 5 Aug 2003 05:10:01 -0000

>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

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

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

---

From: "naresh paliwal" <[email-masked]>
Date: 5 Aug 2003 05:10:01 -0000

-Naresh