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

From: "Susan Hares" <[email-masked]>
Date: Tue, 5 May 2015 18:37:54 -0400

Juan:

Thank you for this feedback.  I will pass this along to Alvaro and discuss
it with Wes. 

Sue 

-----Original Message-----
From: Juan Alcaide [mailto:[email-masked]] 
Sent: Thursday, April 23, 2015 8:17 AM
To: Susan Hares
Cc: 'George, Wes'; 'Jeffrey Haas'; [email-masked]; [email-masked];
'UTTARO, JAMES'
Subject: RE: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Let me be clear. I don't want to revise the FSM.

With the current FSM, internal BGP alias feature will work if we are strict
in how it's implemented. Otherwise, we may have interoperability problems.
Basically, it needs to be specified with AS is tried first.

Just want to make sure the draft says this explicetely (in its current form
it is implied).

-J

> 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
>
>
> 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.