Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

Dear colleagues,

>From my perspective main dispute here is between flexibility and
simplicity. Engineers love flexibility, don't we? But flexibility without
wisdom will bring troubles: I think today BGP needs simplification of
configuration process and strict rules even more than flexibility. I do
support adoption of this draft, but I would like to see specification of
common usages for 32:32:32 as strict as possible (with SHOULD statement)
included in this draft. Otherwise we will still face with results of today
flexibility (AS number is filtered):

>    - remarks: - To prepand or deny prefix use FILTERED:5RSSA, where:
>
>
>    - remarks: R - Geographical region code:
>
>
>    - remarks: 1 - Russia
>
>
>    - remarks: 2 - Europe
>
>
>    - remarks: 3 - Asia
>
>
>    - remarks: 4 - America
>
>
>    - remarks:
>
>
>    - remarks: A - action:
>
>
>    - remarks:
>
>
>    - remarks: 0 - don't announce prefix
>
>
>    - remarks: 1 - announce with one prepend
>
>
>    - remarks: 2 - announce with two times prepend
>
>
>    - remarks: 3 - announce with three times prepend
>
>
>    - remarks:
>
>
>    - remarks:
>
>
>    - remarks: SS - peer number:
>
>
>    - remarks:
>
>
>    - remarks: Russia
>
>
>    - remarks: 01 - Megafon - AS31133
>
>
>    - remarks: 03 - Vimpelcom - AS3216
>
>
>    - remarks: 04 - Comstar - AS8359
>
>
>    - remarks: 10 - Vkontakte - AS47541
>
>
>    - remarks: 11 - Rostelecom - AS12389
>
>
>    - remarks: 12 - Mailru & Odnoklassniki - AS47764
>
>
>    - remarks:
>
>
>    - remarks:
>
>
>    - remarks: Europe
>
>
>    - remarks: 06 - Level3 - AS3356
>
>
>    - remarks: 07 - CHINA TELECOM - AS4134
>
>
>    - remarks: 09 - TeliaSonera - AS1299
>
>
>    - remarks: 14 - Cogent - AS174
>
>
>    - remarks: 15 - TATA - AS6453
>
>
>

2016-09-20 18:50 GMT+03:00 t.petch <ietfc@btconnect.com>:

> ----- Original Message -----
> From: "Robert Raszuk" <robert@raszuk.net>
> To: "Susan Hares" <shares@ndzh.com>
> Cc: "Interminable Discussion Room" <idr@ietf.org>
> Sent: Monday, September 19, 2016 11:38 PM
>
> > Dear Sue,
> >
> > Let me just point out to everyone that when we have been discussing
> > proposal of 32:32:32 and while everyone is in complete agreement for
> the
> > above as described in large-community draft the questioned common
> header is
> > only one option to leave room for future extensible solution even if
> for
> > now we would just stay with use case of simple 32:32:32.
>
> Yes, it does seem clear that this is the only option to provide for
> future enhancements,
>
> It is also clear that the history of protocol development is that there
> is always a need for future enhancements, it is just a matter of when.
>
> But it is also clear that the IETF rarely looks forward more than a
> couple of years or so and so does not see the need for future proofing.
> The counter argument here seems to be code
> complexity, the cost of adding
>
> if bytes xyz == abc, treat as large
> else treat as incomprehensible
>
> Clearly operators want the functionality, can coders cope with the
> complexity?
>
> As to user interface, why change anything now? As and when new options
> appear, then is the time to consider how to offer them to the user,
> which should be the default, which requires extra information and so on.
> For the moment, nothing changes.
>
> Tom Petch
>
>
>
>
>
>
>
> >
> > That is simply standardize communities of the format 32:32:TLV where
> only
> > mandatory TLV today would be say type 1 == 32.
> >
> > IMHO overhead of 3 octets (1 octet for TLV type and 2 for TLV length)
> is
> > negligible as compared with future potential of adding more structures
> to
> > last part of the community as seems fit by IETF WG consensus.
> >
> > Best regards,
> > Robert Raszuk
> >
> > PS. The above is fully compatible with current -large-communities
> draft and
> > I think there is already a proposed text for it.
> >
> >
> > On Mon, Sep 19, 2016 at 11:21 PM, Susan Hares <shares@ndzh.com> wrote:
> >
> > >
> > > Randy
> > > John and I are listening to the frustration in operators.
> > >
> > > Have you exchanged email with Jeff and Jared on their desire for a
> common
> > > header with 1 extra byte to allow policy to track at community
> level?  I
> > > just want to be sure that this switch is frustration + informed
> consent.
> > >
> > >
> > > Sue
> > >
> > > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
> > >
> > > -------- Original message --------
> > > From: Randy Bush <randy@psg.com>
> > > Date: 9/18/16 12:25 PM (GMT-05:00)
> > > To: Sander Steffann <sander@steffann.nl>
> > > Cc: Interminable Discussion Room <idr@ietf.org>
> > > Subject: Re: [Idr] Request to adopt
> draft-heitz-idr-large-community -
> > > Working Group Adoption call (9/6 to 9/20)
> > >
> > > >> can we please focus on the content and let the process go to the
> cloud,
> > > >> where process is processed?
> > > >>
> > > >> is
> > > >>    0                   1                   2                   3
> > > >>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1
> > > >>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>   |                      Autonomous System number
> |
> > > >>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>   |                          Local Data Part 1
> |
> > > >>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>   |                          Local Data Part 2
> |
> > > >>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>
> > > >> sufficient?  that is a binary question.  i am interested in
> answers from
> > > >> operators such as nick, gert, ...
> > > >
> > > > Yep, that seems to do just fine. I like the simplicity.
> > >
> > > while operators keep saying this, it is utterly uncreative and shows
> > > zero cleverness.  how do professional ietf standards makers turn
> this
> > > into resume enhancing material?
> > >
> > > randy
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > Idr@ietf.org
> > > https://www.ietf.org/mailman/listinfo/idr
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > Idr@ietf.org
> > > https://www.ietf.org/mailman/listinfo/idr
> > >
> > >
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: aa@qrator.net
| visit: www.qrator.net