Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

["Susan Hares" <[e-mail]>]

WG, George, Jeff and Juan: 

A revision to the state machine in BGP is outside the scope of this draft.  For those who want to participate in a revision of the state machine, please send me your names.   I will put you on a design team to examine the state machine and provide a draft for the WG group. 

Sue 

-----Original Message-----
From: George, Wes [mailto:[e-mail]] 
Sent: Wednesday, April 22, 2015 5:10 PM
To: Juan Alcaide; Jeffrey Haas
Cc: '[e-mail]'; '[e-mail]'; UTTARO, JAMES; 'Susan Hares'
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

On 4/22/15, 5:20 AM, "Juan Alcaide" <[e-mail]> wrote:


>
>In anycase, since the draft describes multiple vendors implementations, 
>it may be worth to describe the naming of others.

WG] It doesn't really describe any vendors' implementations anymore, but rather an amalgam of multiple implementations, and one of the only places that it does (section 4.1 title) was a mistake that Alvaro caught and I have already fixed in the pending revision. I'd encourage you to re-read the latest draft and identify any places where we are still naming one vendor's implementation such that we need to discuss the naming of others, because we probably need to fix that too.

>
>> You are welcome to provide text for such a thing but I would suggest 
>>it's  not worth the review time of IDR.  The introduction of the 
>>internal toggle  would effectively instantiate a sub-state machine 
>>within the overall state  machine and be quite the mess.  I have long 
>>since lost my notes on the FSM  during RFC 4271 standardization work, 
>>but had noted that it had some issues.
>>
>> Feel free to audit the FSM to see if you can find those issues again 
>>and see  how this would interact with the errata. :-)
>
>Don't want to do a deep inspection of the FSM ;-) It's something more 
>basic. Consider
>
>- You can send only one AS in your open each time you try to establish 
>a new session
>- The As you send does not depend on the AS you receive (no 
>negotiation)
>- You can accept received AS to be accepted if it's one of the 2 
>configured ones
>- You must force AS you send and AS you receive to be the same.

WG] I think the point here is that even this more basic guidance needs to be bashed against what the FSM currently does vs what the spec says it should do (or worse, where the spec is ambiguous and has likely been handled different ways by different vendors) before we can determine where/if it's actually necessary to provide explicit guidance on the matter. The philosophy of the draft has generally been to not be overly proscriptive and discuss the desired behavior, and then let the implementers figure out how that has to work in the guts of their BGP implementation, such as within their implementation of FSM. If you can point to guidance that we need to provide to prevent the desired behavior from being critically altered if it is incorrectly implemented at the FSM level or it otherwise creates interoperability issues for something that is pretty much only locally significant, I can see about adding it, but you will definitely need to provide text, as I am by no means an expert on how this interacts with the FSM.

Thanks
Wes


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.