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

[Ben Maddison <[e-mail]>]

Hi Robert,

I would not support the proposed modification.
The problem that this proposal seeks to address is specifically that the possible range of RFC1997 community values is too small to accommodate the range of semantics that they are intended to communicate. More specifically, it is a common practice amongst operators to express the significance and scope of policy in terms of ASN values, and to map those ASN values into the community values signaling that policy.
By increasing the ASN range without simultaneously increasing the community value range, we broke that mapping. In my opinion, and judging from the views expressed here on this subject, this is the **only** respect in which the current mechanism is broken.
I would personally prefer not to add to the complexity of a solution to a real current problem, in order to fix a hypothetical future problem that no operators seem to be anticipating or remotely concerned about.
All that said, if there are operators out there with real-life use cases requiring a more complex variable-length (of > 12 octets) encoding, then please speak out, and I shall happily eat my words.

Best regards,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     [phone]
Mobile:   [phone]
Email:      [e-mail]<mailto:[e-mail]>
SIP:          [e-mail]<sip:[e-mail]>

[Workonline Communications]<http://www.workonline.co.za/>

From: Idr [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Tuesday, September 20, 2016 1:39 AM
To: Susan Hares <[e-mail]>
Cc: Interminable Discussion Room <[e-mail]>
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

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.

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: 9/18/16 12:25 PM (GMT-05:00)
To: Sander Steffann <[e-mail]<mailto:[e-mail]>>
Cc: Interminable Discussion Room <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr