Re: [bess] AD Review of draft-ietf-bess-fat-pw-bgp-03

Sami Boutros <> Sat, 27 January 2018 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9098612D777; Fri, 26 Jan 2018 16:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z3_qBmurFfDX; Fri, 26 Jan 2018 16:27:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F0D112D7E8; Fri, 26 Jan 2018 16:27:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sq7sqAO1jFmdIO5/xCHsqiB89g66gf2Xjo03mapfo4A=; b=BMsJ1oksdpwaFsEO0Lavf/6ANFj0aMbyQDRufmq7oOUGweHavBQ7+hKhbquuBpaN6f9CDUsuLg44CZk+EXV2OGvfQKTvFkoq8gs6YIfsWZSe+b9Kvk1Q7XxjyOQ69KgJjtq4sNPROuZtv6mbTS5pafJyv3vUKlkEpA/hX46s9DI=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Sat, 27 Jan 2018 00:27:02 +0000
Received: from ([]) by ([]) with mapi id 15.20.0444.011; Sat, 27 Jan 2018 00:27:02 +0000
From: Sami Boutros <>
To: Alvaro Retana <>, "" <>
CC: "" <>, "" <>, Martin Vigoureux <>
Thread-Topic: AD Review of draft-ietf-bess-fat-pw-bgp-03
Thread-Index: AQHTlvA/LNkwW137kk2nBEuvHZHJCaOGVx0A
Date: Sat, 27 Jan 2018 00:27:02 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR05MB3055; 7:stMQirYw0vPUAWo7g7sS0OS2dDUCqeNRB+c3lWARmG1d0IMDpPbCe0JiarAdzI3RTicjZuzZZAGpQt4rMGPq4UxuoyGTG/in8EExhmb2VfveejMf09TgqewSV8rrd4Yl1afS/njyJxobjnNRJaALcxASOQmga+2P5PF4To4slHEHNssB/3sMkjw621StSIMKyrGkYvuhqLj+mkbQs7VziEePdC4zNf2qMZxA+J5o47JiarVvk0Dwqv3PHvzIBgpX; 20:Vrq18+ehMnntFTPz8JDPdK+gdb7Tx9ZJpQfuKcN3t1u8MwMbub7gD2jTE9KKHcCYqdNdINe3NXMkIgIbPNS6N+xMWlxFWNmdZq+MZb+UpEFfFof5dM9m2416z+PrvQ9B5t16E+/XIVQFop4ptl2ZJyra0tL+1Lib6UN0aj07U5k=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 65f616bd-bcd5-4ebb-a71b-08d5651caff6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR05MB3055;
x-ms-traffictypediagnostic: MWHPR05MB3055:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(61668805478150)(192374486261705)(99586504457433)(82608151540597)(85827821059158)(62221491112393)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231079)(2400081)(944501161)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR05MB3055; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3055;
x-forefront-prvs: 056544FBEE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(39380400002)(396003)(366004)(57704003)(199004)(189003)(81156014)(77096007)(110136005)(2501003)(102836004)(6246003)(59450400001)(6486002)(81166006)(105586002)(6436002)(54896002)(36756003)(26005)(53546011)(6506007)(6512007)(33656002)(8936002)(53936002)(316002)(54906003)(236005)(8676002)(229853002)(39060400002)(68736007)(82746002)(99286004)(2950100002)(478600001)(7736002)(8656006)(5660300001)(3660700001)(66066001)(14454004)(76176011)(86362001)(2900100001)(106356001)(186003)(2906002)(4326008)(25786009)(97736004)(3280700002)(3846002)(6116002)(83716003)(345774005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR05MB3055;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: iwwyKJllXPS20ysN38TjRBjQC1orG2RiU3pZn5XYWfA2P7zW7pVKJop46E6gRz9SftWkDlUtiCpthDE6hNc4kA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_9D3EAE0F52914443BCF26549A4F91C8Fvmwarecom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 65f616bd-bcd5-4ebb-a71b-08d5651caff6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2018 00:27:02.6585 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3055
Archived-At: <>
Subject: Re: [bess] AD Review of draft-ietf-bess-fat-pw-bgp-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Jan 2018 00:27:08 -0000

Hi Albaro,

Agreed with all comments, and we can change the “is requesting the ability” to “announce the ability”.

Do we need to submit a new draft with the changes?


From: Alvaro Retana <<>>
Date: Friday, January 26, 2018 at 1:54 PM
To: "<>" <<>>
Cc: "<>" <<>>, "<>" <<>>, Martin Vigoureux <<>>
Subject: AD Review of draft-ietf-bess-fat-pw-bgp-03
Resent-From: <<>>
Resent-To: <<>>, Sami Boutros <<>>, <<>>, <<>>, <<>>
Resent-Date: Friday, January 26, 2018 at 1:54 PM

Dear authors:

I just finished reading this document.  Thank you for a well written and straight forward document!!

I have some comments (see below) that I think are easy to address.  I am then starting the IETF Last Call.




M1. All the rfc2119 keywords in this text should not be capitalized because they are part of an example:

   For example, a PE part of a VPLS and with a local T = 1,
   MUST only transmit traffic with a flow label to those peers that
   signaled R = 1.  And if the same PE has local R = 1, it MUST only
   expect to receive traffic with a flow label from peers with T = 1.
   Any other traffic MUST NOT have a flow label.

M2. Security Considerations: I agree that there are no new issues.  However, please also point to rfc4761 and any other document that defines the base functionality being modified here.


P1. "This draft introduces an OPTIONAL mode of operation..."  There's no need for "OPTIONAL" to be Normative in this sentence since it is just describing what it is, not specifying behavior.  s/OPTIONAL/optional

P2. The new registry has a policy of "IETF Review", which basically means that any RFC (not just Standards Track RFCs) can use the bits in the registry.  I ask because there are only 4 bits left.  Note that I'm not asking you to necessarily change the policy...just pointing it out.

P3. "T   When the bit value is 1, the PE is requesting the ability..."  Did you mean "announce the ability" instead?


P5. References:  I think these can be Informative: rfc4385, rfc8077, rfc4928