Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover
"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Sat, 01 February 2020 20:04 UTC
Return-Path: <zzhang@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B197B120125; Sat, 1 Feb 2020 12:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=NF7TMnI0; dkim=pass (1024-bit key) header.d=juniper.net header.b=bAGEmpBI
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 gnmujzm6DuyV; Sat, 1 Feb 2020 12:04:23 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05480120154; Sat, 1 Feb 2020 12:04:22 -0800 (PST)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 011K4Kee009814; Sat, 1 Feb 2020 12:04:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=vi6AaOGWKGQfliIE2EIcy8p9RErMB+K5dagXy3+QA4I=; b=NF7TMnI08VhXMG7w4XduzqkBUv8uqYvKRBfH76u650uLjghsWyKl35LKG+095kY8v5Oy euvJgUg1MG2mHi+xdBWunOgDtaPUX5pTutunz72oi1pgEi3phGvOmYXmgBGL3Oo9jTCW V/4D7KPfyCq/eHOVSgqeOhaP8eKNvyWHId/adHFqhzQLvAscm590gTcl/PNFI2hcT+O1 2BTTGV5VQavgmD+IpyTIPagyRiGSXWR7cH+SpqF+4IBRqYzIOtCpo+XYHXzTEEyfzucs NbCrhSMPwEhcNxhe7CauWiXNMyscIwJ9p936dN0OOd5y2LI76cHJPBxRXQSXOJMn07oI ag==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2055.outbound.protection.outlook.com [104.47.37.55]) by mx0b-00273201.pphosted.com with ESMTP id 2xw8ff8e35-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Feb 2020 12:04:20 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BMfqb4w7Ab1BTru1jfL0jriqX1VmE8O1xrLwcUxmRv+xaLaTzGsmGhkGOdeh0IBz4Hkff/q2yUWFhgy1gaKVwrtaxYgnum6IHZBgrnwUo+qsuK3sdTDbkAh+9nGdO2C11oXUFSgOX89WljLQGZP0AJKjhw8yJ7YjHuVuHUBH0j/1cmqrlE2ss68PG7Zargx2bOqYwNnUsIV000R3ibGzMZZ48jlSTyD65kHcPw1+ZUPuy44VMQN6W1KN9ABk6BbEv/4j2RQF8heHr6QxZxrXfe0433QskNDHDdE4HmwTSYmistdBy7+iXfPkbbEEOM6Ag/BM7De4g727TFARiFfFsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vi6AaOGWKGQfliIE2EIcy8p9RErMB+K5dagXy3+QA4I=; b=VSpdvvldne7zf+CBplr13HFjhhdaEIxePPSy9ipNGChnszQNVkf4xZ72qj/uPwbBNZYBZMdLnz76bOSS4L//jzWxSgRFlNT4O/+vhan10+SWYFMhg2LnF/aZoSqfr6GuWbnTbFzU1D1ovK+ddh8H7jwc5Q90vsS+Fo/Xxo3hODxt2qME5AMe8pV89HHcQDp9SNwDW7qPBBt1ctJfYyzYCh5A36P214FVtbxu/dDjgztRJvNVKYaEsQBdcr9Ky7FMGy6YM0M3vY/4NjjaSgiZLlgT3JY2zp2vKbTznTUdBx5+Z7k03fScdOqXaeHge+aOKAB/x2Ad4FG9agsY2v3k/w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vi6AaOGWKGQfliIE2EIcy8p9RErMB+K5dagXy3+QA4I=; b=bAGEmpBIrGetVtVOTFWvrdGFxYI3PjFpp1hbP4LztcGL2uARed5wIZdAdUJQff38sLOY9q6FFsx0u2CvWhnWHdU5mENRxDavUKil0VylLqA7h4ZLj8RXIclMSbdUj/eURpIV1FvYvgzU57/FZxmKEzOLUjxrw3ZVRqzj0FsUPaw=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (20.178.240.207) by MN2PR05MB6573.namprd05.prod.outlook.com (20.178.249.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.15; Sat, 1 Feb 2020 20:04:15 +0000
Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::18ab:3d92:bdf8:322d]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::18ab:3d92:bdf8:322d%7]) with mapi id 15.20.2707.018; Sat, 1 Feb 2020 20:04:15 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>
Thread-Topic: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover
Thread-Index: AQHV0WQ8HLiYBTfM5UqstQSAlD0qIqgFNxWAgAAFO4CAABJSgIAABenQgAAG+ICAAABM4A==
Date: Sat, 01 Feb 2020 20:04:15 +0000
Message-ID: <MN2PR05MB598129A9FEF8A5C410EE3D67D4060@MN2PR05MB5981.namprd05.prod.outlook.com>
References: <CA+RyBmWOYUnrzrb=M=dvHpn-huh_WFJURF0spOzX_752V0gkVg@mail.gmail.com> <04f301d5c4a0$6cd81690$468843b0$@gmail.com> <CA+RyBmVsFVz42sbPRF=oJ=wH-dVrZRaMgf+Kqr6ne5SO3HC0+Q@mail.gmail.com> <068e01d5c562$ad9cf7f0$08d6e7d0$@gmail.com> <CA+RyBmUQpVoGQkBcSuXOyf0YQx4PY2oi0z9Z05xtZjZUE-x5BA@mail.gmail.com> <MN2PR05MB5981F2CF3BB66DFD060C6EA2D4070@MN2PR05MB5981.namprd05.prod.outlook.com> <00c901d5d86f$8dd69f00$a983dd00$@gmail.com> <CA+RyBmWBxE_5VkoOR=FpCA0zAnuBYS3X9kYL=SSd1GCpRyMRGA@mail.gmail.com> <MN2PR05MB598164A5F0FD853F69C2A01BD4070@MN2PR05MB5981.namprd05.prod.outlook.com> <CA+RyBmVHurkbsZR7FRRT9bvznQ4YsqzttH91VKUTr=YNTTLXTA@mail.gmail.com>
In-Reply-To: <CA+RyBmVHurkbsZR7FRRT9bvznQ4YsqzttH91VKUTr=YNTTLXTA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.2.8
dlp-reaction: no-action
x-originating-ip: [71.248.165.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4fa0176d-4d2b-4e9d-eaf5-08d7a751ea0e
x-ms-traffictypediagnostic: MN2PR05MB6573:
x-microsoft-antispam-prvs: <MN2PR05MB657399534FCEB9357BB7908ED4060@MN2PR05MB6573.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03008837BD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39850400004)(396003)(136003)(366004)(346002)(376002)(189003)(199004)(81166006)(81156014)(8676002)(33656002)(8936002)(71200400001)(86362001)(66556008)(2906002)(66946007)(64756008)(66446008)(66476007)(30864003)(5660300002)(66574012)(6916009)(52536014)(76116006)(316002)(54906003)(6506007)(9686003)(53546011)(4326008)(55016002)(7696005)(478600001)(186003)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB6573; H:MN2PR05MB5981.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Vs9AJPwA/xpcszFWikgcE8xfPopsUGVzclIMmZxHG8SxIvzUz9q2mmWy8DMNv0wS4Tc130T8vFljMe7/hzB3y0VVE0kYgqcWxyVHkvSwKPNS336eFDQDu3i5So5FvVRzdwVmvydemgiHlhyl2Vh4GPjhrXC1aUGMGMPeVrmKnh1PXXipaBBvzKu/lFVzaoEkwIkB7X6Za2/B3cPCln4ROJFt/VWpynwdQIE3TX0XVawCa4GsuF9/ztZuz0bKGgIpemqt+JvbIU2A9NZ/8hx+S4/UCdwRoGlFe8g7hUKi2FV96nGRxTa5pJ403ssWRxVpovh4FiagOUqWXRkF2nRPmOs8hDnp8Wy5TKZzSitqlIgrO6QozH4qBDxaqJ7KjP2AM/N+W1ZZikqXW4tDGLFbDT1ROVt4dTRvojsYcxBAh6VKOplty52ODWgLWPyAF16+
x-ms-exchange-antispam-messagedata: poBnVDgWny+vJds0k70ibDeIX95JX4uTD6dSanjvOJLSzfzx2YLfknNKzjIU5WLUbbA0ktDvxXL0wBURxfFioAeH32/w+oLXcPvxqhkGA6JNud8cpeNN7aGTp+J4OzIrT6wvq6t9RaxLSGw1qIMl2g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR05MB598129A9FEF8A5C410EE3D67D4060MN2PR05MB5981namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fa0176d-4d2b-4e9d-eaf5-08d7a751ea0e
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2020 20:04:15.5151 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aV31vkwOj214h4uOIgDgL3YK44IB5auU3rApqf3XRuWvuirLSOWkjZIskmL/yjRjFh3qa+de02Qj26daKJkZng==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6573
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-01_04:2020-01-31, 2020-02-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 adultscore=0 mlxlogscore=999 impostorscore=0 suspectscore=0 clxscore=1015 bulkscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 mlxscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002010144
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/c0jkbOelnxNyM2j152-SuO6BNj0>
Subject: Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2020 20:04:27 -0000
Right š From: Greg Mirsky <gregimirsky@gmail.com> Sent: Friday, January 31, 2020 4:41 PM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> Cc: slitkows.ietf@gmail.com; bess-chairs@ietf.org; BESS <bess@ietf.org> Subject: Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover Hi Jeffrey, my apologies, I misunderstood your proposed change. Should it be the following change: OLD TEXT The downstream PE can immediately update its UMH when the reachability condition changes. NEW TEXT As a result, the downstream PE can immediately update its UMH when the reachability condition changes. Thank you for your help. Regards, Greg On Fri, Jan 31, 2020 at 1:16 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote: In 3.1.4 you missed āas a resultā. From: BESS <bess-bounces@ietf.org<mailto:bess-bounces@ietf.org>> On Behalf Of Greg Mirsky Sent: Friday, January 31, 2020 3:55 PM To: slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com> Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; BESS <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-fast-failover Hi Jeffrey, many thanks for your suggestions. I've updated the document accordingly. I much appreciate you checking that changes are in the right places. I'll upload the new version ones you approve the changes. Regards, Greg On Fri, Jan 31, 2020 at 11:49 AM <slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com>> wrote: Iām fine with the proposal From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> Sent: vendredi 31 janvier 2020 20:44 To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com> Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover Hi Greg, Stephane, The first MAY should actually be a SHOULD; for the second MAY, it actually can go back to ācanā. Then this will match the previous RSVP-TE section. The āin this caseā sentence is more about the result, not the action to take. Perhaps also change āin this caseā to āas a resultā in both sections? Jeffrey From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> Sent: Wednesday, January 22, 2020 3:41 PM To: slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-fast-failover Hi Jeffrey, happy New Years (the Spring Festival is just upon us) and best wishes. Stephane suggested to ask you another, hopefully quick, review of the part of this draft. Please see our discussion copied below: Section 3.1.4: As the document is standard track, could you introduce normative language in the expected behavior description ? GIM>> Updating to the normative language as follows: OLD TEXT: A PE can be removed from the UMH candidate list for a given (C-S, C-G) if the P-tunnel (I or S, depending) for this (S, G) is leaf triggered (PIM, mLDP), but for some reason internal to the protocol the upstream one-hop branch of the tunnel from P to PE cannot be built. In this case, the downstream PE can immediately update its UMH when the reachability condition changes. NEW TEXT: A PE MAY be removed from the UMH candidate list for a given (C-S, C-G) if the P-tunnel (I-PMSI or S-PMSI) for this (S, G) is leaf- triggered (PIM, mLDP), but for some reason internal to the protocol the upstream one-hop branch of the tunnel from P to PE cannot be built. In this case, the downstream PE MAY immediately update its UMH when the reachability condition changes. [SLI] I understand the first āMAYā as optional feature, however the second āMAYā is more a āSHOULDā IMO. Thoughts? GIM2>> Thank you for the clarification. The UMH list will certainly be updated once the reachability of the downstream PE changes. In some scenarios, such an update may be immediate, i.e., ASAP, but in some, it might be better to delay it. Would you suggest adding a note about the option to delay the update? [SLI] Could you check with Jeffrey Zhang on this point ? Iām not enough expert here to tell what may be the best option. On my side, I just want the text to be clear š What do you think of the use of the normative language in the newly updated text? Best regards, Greg On Tue, Jan 7, 2020 at 5:59 AM <slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com>> wrote: Hi Greg, More inline, From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> Sent: mercredi 4 dĆ©cembre 2019 23:22 To: slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com>; BESS <bess@ietf.org<mailto:bess@ietf.org>>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: RE: Shepherd's review of draft-ietf-bess-mvpn-fast-failover Hi Stephane, thank you for the review and your thoughtful comments. Please find my answers and notes in-lined under GIM>> tag. Attached, please find the diff and copy of the working version. Regards, Greg Hi, Please find below my review of the document. Nits: Section 3.1.1: As the document is standard track, could you introduce normative language in the expected behavior description ? GIM2>> My apologies, I've pasted the same text twice. I propose to remove "may be omitted" altogether. Hence the updated text: If BGP next-hop tracking is done for VPN routes and the root address of a given tunnel happens to be the same as the next-hop address in the BGP auto-discovery route advertising the tunnel, then the use of this mechanism for the tunnel will not bring any specific benefit. Do you see this version without any normative language as acceptable? [SLI] Looks good thanks Section 3.1.2: As the document is standard track, could you introduce normative language in the expected behavior description ? āThis method should not be usedā. Wouldnāt this be a normative statement ? GIM>> Would the following modification of the text be acceptable: OLD TEXT: This method should not be used when there is a fast restoration mechanism (such as MPLS FRR [RFC4090]) in place for the link. NEW TEXT: Using this method when a fast restoration mechanism (such as MPLS FRR [RFC4090]) is in place for the link requires careful consideration and coordination of defect detection intervals for the link and the tunnel. In many cases, it is not practical to use both methods at the same time. [SLI] Are we strongly disencouraging the practice ? if yes, āit is not practicalā is a bit too soft. Iām wondering if āis NOT RECOMMENDEDā could be a good wording. But it is up to you. GIM2>> The use of OAM in multi-layer fashion is a question I'd be interested to discuss. But I feel that it deserves a separate document and would prefer to leave the text as a note of caution for now. [SLI] Ok Section 3.1.4: As the document is standard track, could you introduce normative language in the expected behavior description ? GIM>> Updating to the normative language as follows: OLD TEXT: A PE can be removed from the UMH candidate list for a given (C-S, C-G) if the P-tunnel (I or S, depending) for this (S, G) is leaf triggered (PIM, mLDP), but for some reason internal to the protocol the upstream one-hop branch of the tunnel from P to PE cannot be built. In this case, the downstream PE can immediately update its UMH when the reachability condition changes. NEW TEXT: A PE MAY be removed from the UMH candidate list for a given (C-S, C-G) if the P-tunnel (I-PMSI or S-PMSI) for this (S, G) is leaf- triggered (PIM, mLDP), but for some reason internal to the protocol the upstream one-hop branch of the tunnel from P to PE cannot be built. In this case, the downstream PE MAY immediately update its UMH when the reachability condition changes. [SLI] I understand the first āMAYā as optional feature, however the second āMAYā is more a āSHOULDā IMO. Thoughts? GIM2>> Thank you for the clarification. The UMH list will certainly be updated once the reachability of the downstream PE changes. In some scenarios, such an update may be immediate, i.e., ASAP, but in some, it might be better to delay it. Would you suggest adding a note about the option to delay the update? [SLI] Could you check with Jeffrey Zhang on this point ? Iām not enough expert here to tell what may be the best option. On my side, I just want the text to be clear š Section 3.1.6: As the document is standard track, could you introduce normative language in the expected behavior description ? GIM>> Sub-sections of 3.1..6 define the use of RFC 8562 and the new attribute. In the introduction to these sub-sections, I propose s/can/MAY/ >From a wider perspective, do you foresee other use case of signaling BFD information in BGP ? Iām just wondering if we may need something extensible for future use or not. GIM>> Great question. BGP, and I'm speculating here, may be used to for other BFD-related scenarios. I think that we may use the Flags field. [SLI] Is it enough or should you add some optional TLVs behind the discriminator ? (with nothing defined yet). GIM2>> Great idea, thank you! Please see the updated figure and the text: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format of the BFD Discriminator Attribute Where: BFD Mode is the one octet long field. This specification defines the P2MP value (TBA3) Section 7.1. Reserved field is three octets long and the value MUST be zeroed on transmission and ignored on receipt. BFD Discriminator is four octets long field. Reserved TLV field is four octets long. It MAY be used for future extensions of the BFD Discriminator Attribute using Type-Length- Value format. This specification defines that the value in Reserved TLV field MUST be zeroed on transmission and ignored on receipt. [SLI] If your field is 4-bytes long, it is not extensible, I was thinking of options encoded as TLVs. If there is no TLV, the attribute ends on BFD discriminator, the attribute length should tell if there are TLVs or not. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Another point I have missed, you should define error handling procedures for your attribute as per RFC7606.
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ slitkows.ietf
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- [bess] Shepherd's review of draft-ietf-bess-mvpn-ā¦ slitkows.ietf
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ slitkows.ietf
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ slitkows.ietf
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Jeffrey (Zhaohui) Zhang
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ slitkows.ietf
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Jeffrey (Zhaohui) Zhang
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Jeffrey (Zhaohui) Zhang
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ slitkows.ietf
- Re: [bess] Shepherd's review of draft-ietf-bess-mā¦ Greg Mirsky