Re: [j-nsp] JUNOS not compliant with RFC 3392?
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?
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?
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