Re: [j-nsp] JUNOS not compliant with RFC 3392?

2009-03-30 Thread Jonathan Looney
If what you describe is true, it does not make JUNOS non-compliant with RFC
3392.  The word "SHOULD" is defined in RFC 2119:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.


Therefore, failure to behave in this way would not make any OS
non-compliant.  It would just mean that they chose not to implement a
general recommendation in these particular circumstances.

Having said that, as I recall, there is a difference between not supporting
a particular capability and not supporting capabilities negotiation in
general.  Do you know which type of notification the Checkpoint is
generating?

-Jon

On Mon, Mar 30, 2009 at 4:13 PM, Derick Winkworth wrote:

> All:
>
> We are establishing a BGP session between an M120 and a Checkpoint
> firewall.  The Checkpoint does not support 4-byte ASs.  It is sending the
> Notification to the M120 indicating so, but the M120 keeps sending the
> capability code everytime it trys to reestablish.
>
> Doesn't that make JUNOS non-compliant with RFC 3392?
>
> 
> A BGP speaker determines that its peer doesn't support capabilities
>advertisement, if in response to an OPEN message that carries the
>Capabilities Optional Parameter, the speaker receives a NOTIFICATION
>message with the Error Subcode set to Unsupported Optional Parameter.
>In this case the speaker SHOULD attempt to re-establish a BGP
>connection with the peer without sending to the peer the Capabilities
>Optional Parameter.
> #
>
>
> In the meantime, we used the hidden command "disable-4byte-as." to
> establish connectivity.
>
> Derick
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] JUNOS not compliant with RFC 3392?

2009-03-30 Thread Derick Winkworth
I just re-read this and realized that it says the speaker "SHOULD" try again 
without the code.  It doesn't say "MUST."  So technically, its compliant.  If 
Juniper chooses not to follow the recommendation of trying again without the 
code, then why is the "disable-4byte-as" command hidden?





From: Derick Winkworth 
To: juniper-nsp@puck.nether.net
Sent: Monday, March 30, 2009 3:13:35 PM
Subject: JUNOS not compliant with RFC 3392?


All:

We are establishing a BGP session between an M120 and a Checkpoint firewall.  
The Checkpoint does not support 4-byte ASs.  It is sending the Notification to 
the M120 indicating so, but the M120 keeps sending the capability code 
everytime it trys to reestablish.

Doesn't that make JUNOS non-compliant with RFC 3392?


A BGP speaker determines that its peer doesn't support capabilities
   advertisement, if in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   In this case the speaker SHOULD attempt to re-establish a BGP
   connection with the peer without sending to the peer the Capabilities
   Optional Parameter.
#


In the meantime, we used the hidden command "disable-4byte-as." to establish 
connectivity.

Derick
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] JUNOS not compliant with RFC 3392?

2009-03-30 Thread Derick Winkworth
All:

We are establishing a BGP session between an M120 and a Checkpoint firewall.  
The Checkpoint does not support 4-byte ASs.  It is sending the Notification to 
the M120 indicating so, but the M120 keeps sending the capability code 
everytime it trys to reestablish.

Doesn't that make JUNOS non-compliant with RFC 3392?


A BGP speaker determines that its peer doesn't support capabilities
   advertisement, if in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   In this case the speaker SHOULD attempt to re-establish a BGP
   connection with the peer without sending to the peer the Capabilities
   Optional Parameter.
#


In the meantime, we used the hidden command "disable-4byte-as." to establish 
connectivity.

Derick
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp