Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt

Christoph Loibl <c@tix.at> Sat, 04 March 2017 19:08 UTC

Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67AA129567 for <idr@ietfa.amsl.com>; Sat, 4 Mar 2017 11:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJk6CwXIhaMI for <idr@ietfa.amsl.com>; Sat, 4 Mar 2017 11:08:26 -0800 (PST)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B303A129563 for <idr@ietf.org>; Sat, 4 Mar 2017 11:08:25 -0800 (PST)
Received: from 80-110-123-147.cgn.dynamic.surfer.at ([80.110.123.147] helo=[192.168.66.245]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1ckErU-0004W7-ED; Sat, 04 Mar 2017 19:57:01 +0100
Content-Type: multipart/signed; boundary="Apple-Mail=_25AB4334-F4EE-47E5-BC68-84A5A09E704F"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Christoph Loibl <c@tix.at>
X-Priority: 3
In-Reply-To: <2017030422011941402723@chinamobile.com>
Date: Sat, 04 Mar 2017 20:08:17 +0100
Message-Id: <12F0808C-8AFD-4BD9-A7D6-E493F0833B2E@tix.at>
References: <148784903318.20350.3977002902067988959.idtracker@ietfa.amsl.com> <2017030317434995427747@chinamobile.com> <FA259FC3-0593-42A0-8A71-03D75CD6D527@tix.at> <2017030422011941402723@chinamobile.com>
To: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YmvNtx65JFVaEGJRcxepHooAg2E>
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Mar 2017 19:08:30 -0000

Hi,

Your comment makes sense to me. I collected a few other minor changes over the last months (that I received as feedback) and added your comment to this list. In about two weeks I will be ready to upload a new version of our draft, after discussing that with the other authors.

Thanks for your feedback!

Cheers

Christoph


> On 4 Mar 2017, at 15:01, lizhenqiang@chinamobile.com wrote:
> 
> Hi,
> 
> Since the sub sections of section 7 in this draft are organised according to the sub type of the extended community, I think the following table format for table 2 is better and easier to read. Maybe it can be further improved. Cross references shown in the table are also acceptable. You can also consider changing the title of section 7.4 from IP redirect to VRF redirect, because the traffic is not redirected to an IP address but a VRF. Redirect to IP is being discussed in a seperate draft.
> 
>    +--------+----------------------+-----------------------------------+
>    | type   | extended community   | encoding                          |
>    +--------+----------------------+-----------------------------------+
>    | 0x8006 | traffic-rate-bytes   | 2-byte ASN, 4-byte float          |
>    | 0x8007 | traffic-action       | bitmask                           |
>    | 0x8008 | VRF-redirect         | 2-octet AS, 4-octet value         |
>    | 0x8108 | VRF-redirect         | 4-octet IPv4 addres, 2-octet      |
>    |        |                      | value                             |
>    | 0x8208 | VRF-redirect         | 4-octet AS, 2-octet value         |
>    | 0x8009 | traffic-marking      | DSCP value                        |
>    | TBD    | traffic-rate-packets | 2-byte ASN, 4-byte float          |
>    +--------+----------------------+-----------------------------------+
> 
> Best Regards,
> 
> lizhenqiang@chinamobile.com <mailto:lizhenqiang@chinamobile.com>
> 
> From: Christoph Loibl <mailto:c@tix.at>
> Date: 2017-03-03 18:23
> To: lizhenqiang@chinamobile.com <mailto:lizhenqiang@chinamobile.com>
> CC: idr <mailto:idr@ietf.org>
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt
> Hi,
> 
> There are 5 basic actions (extended community sub-type 6,7,8,9,TBD = traffic-rate-bytes, traffic-action, redirect, traffic-marking, traffic-rate-packets). However for the redirect action there exist 3 different route-target encoding formats (extended community sub-type 0x08 + type 0x80, 0x81 and 0x82):
> 
> | 0x8008 | redirect AS-2byte    | 2-octet AS, 4-octet value         |
> | 0x8108 | redirect IPv4        | 4-octet IPv4 addres, 2-octet      |
> |        |                      | value                             |
> | 0x8208 | redirect AS-4byte    | 4-octet AS, 2-octet value         |
> 
> These three encoding formats are explained in our draft section 7.4 (IP Redirect sub-type 0x08) and basically use the same encoding as described in RFC 4360 and RFC 5668.
> 
> Do you think that additional clarification or a cross-reference from the table to this secion is needed for each action?
> 
> Cheers,
> 
> Christoph
> 
> 
>> On 3 Mar 2017, at 10:43, lizhenqiang@chinamobile.com <mailto:lizhenqiang@chinamobile.com> wrote:
>> 
>> Hi,
>> 
>> I am reading this draft. I noticed that there are 7 actions listed in table 2. But Only 5 of them are illustrated in section 7. Actions for type 0x8108 and 0x8208 are not explained in this section. No references are given here. May I know the reason? Thanks.
>> 
>> Best Regards,
>> lizhenqiang@chinamobile.com <mailto:lizhenqiang@chinamobile.com>
>> 
>> From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>> Date: 2017-02-23 19:23
>> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>> CC: idr@ietf.org <mailto:idr@ietf.org>
>> Subject: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Inter-Domain Routing of the IETF.
>> 
>>         Title           : Dissemination of Flow Specification Rules
>>         Authors         : Susan Hares
>>                           Robert Raszuk
>>                           Danny McPherson
>>                           Christoph Loibl
>>                           Martin Bacher
>> Filename        : draft-ietf-idr-rfc5575bis-00.txt
>> Pages           : 30
>> Date            : 2017-02-22
>> 
>> Abstract:
>>    This document updates RFC5575 which defines a Border Gateway Protocol
>>    Network Layer Reachability Information (BGP NLRI) encoding format
>>    that can be used to distribute traffic flow specifications.  This
>>    allows the routing system to propagate information regarding more
>>    specific components of the traffic aggregate defined by an IP
>>    destination prefix.  This draft specifies IPv4 traffic flow
>>    specifications via a BGP NLRI which carries traffic flow
>>    specification filter, and an Extended community value which encodes
>>    actions a routing system can take if the packet matches the traffic
>>    flow filters.  The flow filters and the actions are processed in a
>>    fixed order.  Other drafts specify IPv6, MPLS addresses, L2VPN
>>    addresses, and NV03 encapsulation of IP addresses.
>> 
>>    This document updates RFC5575 to correct unclear specifications in
>>    the flow filters and to provide rules for actions which interfere
>>    (e.g. redirection of traffic and flow filtering).
>> 
>>    Applications which use the bgp flow specification are: 1) application
>>    which automate of inter-domain coordination of traffic filtering,
>>    such as what is required in order to mitigate (distributed) denial-
>>    of-service attacks; 2) application which control traffic filtering in
>>    the context of a BGP/MPLS VPN service, and 3) applications with
>>    centralized control of traffic in a SDN or NFV context.  Some of
>>    deployments of these three applications can be handled by the strict
>>    ordering of the BGP NLRI traffic flow filters, and the strict actions
>>    encoded in the Extended Community Flow Specification actions.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ <https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/>
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-00 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-00>
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org <mailto:Idr@ietf.org>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org <mailto:Idr@ietf.org>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> --
> Christoph Loibl
> c@tix.at <mailto:c@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at <http://www.nextlayer.at/>
--
Christoph Loibl
c@tix.at <mailto:c@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at <http://www.nextlayer.at/>