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

"George, Wes" <> Wed, 22 April 2015 21:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 30DF71A8983 for <>; Wed, 22 Apr 2015 14:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.475
X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DgilqpYizgLa for <>; Wed, 22 Apr 2015 14:11:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9DFFF1A8A12 for <>; Wed, 22 Apr 2015 14:11:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,626,1422939600"; d="scan'208";a="857380466"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 22 Apr 2015 16:54:59 -0400
Received: from ([]) by ([]) with mapi; Wed, 22 Apr 2015 17:10:30 -0400
From: "George, Wes" <>
To: Juan Alcaide <>, Jeffrey Haas <>
Date: Wed, 22 Apr 2015 17:10:29 -0400
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt
Thread-Index: AdB9QMNdKC1UINO9QQ+H654k8g4F2w==
Message-ID: <>
References: <> <> <02e401d072e4$4f5a1cc0$ee0e5640$> <> <> <001f01d07b3f$13ee12f0$3bca38d0$> <> <> <20150421202647.GB1600@pfrc> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "''" <>, "''" <>, "UTTARO, JAMES" <>, 'Susan Hares' <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Apr 2015 21:11:41 -0000

On 4/22/15, 5:20 AM, "Juan Alcaide" <> wrote:

>In anycase, since the draft describes multiple vendors implementations,
>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
>> not worth the review time of IDR.  The introduction of the internal
>> would effectively instantiate a sub-state machine within the overall
>> machine and be quite the mess.  I have long since lost my notes on the
>> during RFC 4271 standardization work, but had noted that it had some
>> 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.


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.