Re: [Idr] Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)

["Alvaro Retana (aretana)" <[e-mail]>]

On 2/19/15, 7:29 PM, "George, Wes" <[e-mail]> wrote:

Wes:

Hi!

Hard to snip stuff out..

..

>On 2/19/15, 9:25 AM, "Adrian Farrel" <[e-mail]> wrote:
>
>>The document seems to address four topics:
>>- Requirements for and circumstances of AS migration
>>- Behavior needed from a BGP system when migrating AS numbers
>>- Mechanisms that a BGP implementation can use to provide the
>>  behavior
>>- Description of the mechanisms and configuration options contained in
>>  specific implementations
>>
>>. . .
>>
>>The third bullet is somewhat suspect. Maybe it is an advisory appendix,
>>but the list of ways to provide the function is unbounded and there is
>>no requirement for interoperability. I am not sure that publshing this
>>information is a great benefit. Maybe it is not harmful although it
>>might tend to reduce innovation and give vendors and operators
>>expectations about mechanisms that should be used within
>>implementations.
>
>WG] As noted elsewhere, this is a locally specific implementation, so
>interop isn't required. Consistency of behavior is useful, but I'm not
>convinced that we're going to be able to force that by being more generic
>and more prescriptive, nor am I convinced that there is much innovation to
>be had here such that we'd stifle it.
>IETF has a decision point here: do we document the desired behavior as if
>no implementations currently exist and then reserve any acknowledgment of
>the existing implementations for an implementation report or appendix, or
>do we acknowledge that we're documenting existing behaviors as something
>like the union of the features provided across the different
>vendor-specific implementations? There is precedent for documenting one
>vendor's implementation of something when they want to make it available
>to other implementers, but I'm not aware of any precedent for this when
>it's multiple vendors such as this document, especially when none of the
>vendors in question are authors.
>IMO, the problem with the first choice is that we now find ourselves in
>the situation where we are essentially telling vendors that their existing
>implementations are not compliant with our ex post facto standard, and I'm
>not sure that has any real benefit. As people are fond of saying, IETF
>isn't the protocol police, but when customers ask vendors for support of a
>certain feature, if there's an RFC that documents it, they often refer to
>it in shorthand as "support for RFCnnnn" with the expectation that it will
>be fully supported without having to explain every possible part of the
>desired feature or behavior.
>This draft took a more pragmatic view, "...Rough consensus and running
>code." and all that...

The problem I have with the current text is that it basically reads: ³we
want the behavior to be like cisco¹s local-as² (as an example).  While
(not wearing any hats) I love cisco¹s implementation of local-as, I¹m left
with the sense that others are better off just reading the on-line
documentation..which may of course change at any point.

If you really want the behavior of (todays) cisco¹s local-as, then
document its current behavior, and ack the existing implementations in an
appendix.  This is similar to the ³first choice² you mentioned above in
that the description of the behavior is separate from the commercial
implementation, even if they do the same thing.

In the draft you focused on the local-as (and options) functionality in
Section 3 and 'Internal BGP Alias' in Section 4.  I think you were right
in describing the internal and external behaviors separately, which I
think means that the functionality is not really the union of features,
but two independent features.


>
>>
>>I find the final bullet very suspect. It goes beyond an implementation
>>report and enters into the world of sales. While the document makes no
>>explicit analysis of the pros and cons of the different implementations,
>>described, there is a lot between the lines. Furthermore, by not
>>documenting the mechanisms in other implementations, the document gives
>>the false impression that the three implementations described are the
>>benchmark for AS migration. It might be possible to move this material
>>to an appendix or a separate implementation document, but as the authors
>>note, much or all of the information can be found on the websites of the
>>companies concerned, and I think that is where it should stay.
>
>WG] IDR requires implementation/interop reports. Given that this is a bit
>of a "cart before horse" situation, where we are documenting existing
>implementations, I think some mention of the vendor-specific
>implementations is necessary. The info can be found on the websites, but
>given that at least one of those links had gone 404 in the time since the
>initial draft was written and had to be updated, I do not hold much hope
>that the URIs will actually be useful references as this document ages.
>Whether that means we need more info in the document instead is open for
>discussion.
>As to "you used C and J in your examples but not A or H or..." - There are
>representatives from all of those vendors present at IETF and AFAIK
>participating in IDR, and they are more than welcome to contribute text to
>address the concern around unequal discussion of each vendor-specific
>implementation within the draft. No slight or endorsement was intended.
>That said, I am not convinced that a complete documentation of every
>vendor's flavor of this is useful or appropriate, and your comments seem
>to agree.
>The authors chose examples based on what we were familiar with. Already we
>struggled with the issue of terminology, because I got reviews from folks
>at both C and J who got cross if I used the other's term or didn't
>document the behavior exactly as they implemented it, but it didn't make
>sense to invent completely new terms just to avoid using one of the
>pre-existing terms. Additionally, because this behavior was initially
>vendor-specific, there is a non-trivial amount of overlap between
>implementations. Basically, an operator looked at a feature provided by
>one vendor and told another either "do it like that" or "do it mostly like
>that, but give me this additional optimization". We tried to split the
>difference with the normative text. So I guess the question is whether or
>not this document stands alone/is useful with just the normative text and
>much less in the way of examples to tie it to the existing
>implementations. Randy's comments seem to say yes (though he was
>commenting more specifically on the business drivers). I will go with
>consensus on the matter.

I think examples are ok (in an appendix), specially if the base of the
behavior is an already existing and deployed feature, as it is here.

Personally, I would stay away form trying to show examples for all
possible variations and all possible vendors, and focus on the specific
functionality you¹re addressing.

Thanks!

Alvaro.