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

"" <> Sat, 04 March 2017 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5608A1294C1 for <>; Sat, 4 Mar 2017 06:01:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aHdVmbbhdYpN for <>; Sat, 4 Mar 2017 06:01:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9C3651293DF for <>; Sat, 4 Mar 2017 06:01:00 -0800 (PST)
Received: from (unknown[]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee358bac895f56-f7585; Sat, 04 Mar 2017 22:00:53 +0800 (CST)
X-RM-TRANSID: 2ee358bac895f56-f7585
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea58bac893143-4c296; Sat, 04 Mar 2017 22:00:53 +0800 (CST)
X-RM-TRANSID: 2eea58bac893143-4c296
Date: Sat, 4 Mar 2017 22:01:20 +0800
From: "" <>
To: "Christoph Loibl" <>
References: <>, <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 164[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart783784630356_=----"
Archived-At: <>
Cc: idr <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Mar 2017 14:01:05 -0000


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,
From: Christoph Loibl
Date: 2017-03-03 18:23
CC: idr
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc5575bis-00.txt

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?



On 3 Mar 2017, at 10:43, wrote:


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,
Date: 2017-02-23 19:23
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
   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:
There's also a htmlized version available at:
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at
Internet-Drafts are also available by anonymous FTP at:
Idr mailing list
Idr mailing list

Christoph Loibl | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 |