Re: [mpls] MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Italo Busi <Italo.Busi@huawei.com> Fri, 17 April 2020 08:34 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F353A10AE; Fri, 17 Apr 2020 01:34:29 -0700 (PDT)
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, SPF_PASS=-0.001, URIBL_BLOCKED=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 odjEn3Fzm1NN; Fri, 17 Apr 2020 01:34:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 EEBED3A10AD; Fri, 17 Apr 2020 01:34:25 -0700 (PDT)
Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 87AE2522696DEDB1D3EF; Fri, 17 Apr 2020 09:34:23 +0100 (IST)
Received: from fraeml712-chm.china.huawei.com (10.206.15.61) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Apr 2020 09:34:23 +0100
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Apr 2020 10:34:22 +0200
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.1913.007; Fri, 17 Apr 2020 10:34:22 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: Shraddha Hegde <shraddha@juniper.net>, "draft-hegde-mpls-spring-epe-oam@ietf.org" <draft-hegde-mpls-spring-epe-oam@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, Mach Chen <mach.chen@huawei.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Sam Aldrin <aldrin.ietf@gmail.com>
Thread-Topic: MPLS-RT review of draft-hegde-mpls-spring-epe-oam
Thread-Index: AQHV4vKin/ts0EbuOkuowWYDGxi83agtpLqggA3MeICAO8QBAIAGKAfQ
Date: Fri, 17 Apr 2020 08:34:22 +0000
Message-ID: <b1a5d9d2d86d4f68b36e6badf1a5b25d@huawei.com>
References: <2141e262-752f-0c7e-fdcb-03aea45e9aa1@pi.nu> <5aa73bfd247040d4bae8131f4eb43b5f@huawei.com> <BYAPR05MB3943F01C099FF220BA553958D5E30@BYAPR05MB3943.namprd05.prod.outlook.com> <CY4PR05MB35768847A45FA06732A24E8CD5DD0@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB35768847A45FA06732A24E8CD5DD0@CY4PR05MB3576.namprd05.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.24.240]
Content-Type: multipart/related; boundary="_004_b1a5d9d2d86d4f68b36e6badf1a5b25dhuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/r9sY9jEUzo57itpjqyklyLlwHhc>
Subject: Re: [mpls] MPLS-RT review of draft-hegde-mpls-spring-epe-oam
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2020 08:34:30 -0000

Hi Shraddha,

Thanks for your update: I am ok with the latest changes

While I support the addition of section 5, my comments on figure 2 and 3 were considering more “basic” validation that the sub-TLV is not malformed

Let’s consider figure 2, I guess the receiver should check that:

   Length = 20 + “No.of IPv4 interface pairs” * 8 + “No.of IPv6 interface pairs ” * 32

I was just wondering whether it is worthwhile making this requirement explicit in the draft.

I take the opportunity to point out a nit in section 5: the text needs to be reformatted to comply with the RFC line width requirements

Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.busi@huawei.com
[cid:image003.png@01D614A3.CBCCCDF0]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Shraddha Hegde [mailto:shraddha@juniper.net]
Sent: lunedì 13 aprile 2020 14:23
To: Italo Busi <Italo.Busi@huawei.com>; draft-hegde-mpls-spring-epe-oam@ietf.org; mpls-chairs@ietf.org; Mach Chen <mach.chen@huawei.com>
Cc: mpls@ietf.org; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; Sam Aldrin <aldrin.ietf@gmail.com>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hi Italo,

An updated version -06 is posted addressing comments.
Pls take a look.

Rgds
Shraddha


From: Shraddha Hegde
Sent: Friday, March 6, 2020 4:12 PM
To: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>; draft-hegde-mpls-spring-epe-oam@ietf.org<mailto:draft-hegde-mpls-spring-epe-oam@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>>; Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; Sam Aldrin <aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hi Italo,

Thanks for review and comments. Pls see inline…

From: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
Sent: Wednesday, February 26, 2020 10:30 PM
To: draft-hegde-mpls-spring-epe-oam@ietf.org<mailto:draft-hegde-mpls-spring-epe-oam@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>>; Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; Sam Aldrin <aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hi all,

I have been selected as one of the  MPLS-RT reviewers of draft-hegde-mpls-spring-epe-oam.

I have reviewed the latest version of the draft which has been published two days ago (draft-hegde-mpls-spring-epe-oam-05).

I think that the document is coherent, is it useful (i.e., it addresses a real need for operational networks), and it is technically sound.

Therefore, I think that the draft is ready to be adopted as a WG document.

I have few comments that can be addressed either before or after WG adoption.

1.       The Introduction mentions the procedures defined in section 7 of RFC8287 and clarified by RFC8690.

My understanding is that RFC8690 clarifies how to use the length field with the sub-TLVs defined in section 5 of RFC8287 and therefore it is not strictly applicable to this draft.
<shraddha> yes. You are right. I updated this sentence and referred 8690 based on comment that 8287
Has an important clarification in RFC 8690 so it should be reference.

However, it would be worthwhile clarifying in section 4 of this draft how the length field should be set for the EPE SID sub-TLVs. An example would also be useful.
<shraddha> yes updated the draft.

2.       I guess that all the information elements used in the sub-TLVs defined in section 4 of this draft are those defined in draft-ietf-idr-bgpls-segment-routing-epe.
<Shraddha> Yes.

It would be worthwhile to reference draft-ietf-idr-bgpls-segment-routing-epe for these definitions.
<Shraddha> yes, normative reference added.

I guess this would also help resolving comment #1 from Sasha on link-local IPv6 addresses and unnumbered interfaces: whatever is supported by draft-ietf-idr-bgpls-segment-routing-epe should be also supported by this draft (and vice versa)
<shraddha> updated with link-local addresses FFS.

3.       In Figure 2, the “No.of IPv6 interface pairs” field seems a bit redundant since the information can be inferred from the “Length” and “No.of IPv4 interface pairs ” fields
<shraddha> Since IPv4 and ipv6 address pair may be present simultaneously, we need this field.

This is ok for me but please add some text to clarify whether the receiver should/shall perform some validation check
 <shraddha> sure will add new section in next revision.
4.       Figure 3 is not fully clear

If I understand well, the “Remote As Number”, “Remote BGP Router ID”, “No.of IPv4 interface pairs”, … fields are repeated for each element in the set.
<Shraddha> yes, these elements are repeated for each set.

It may be worthwhile to split the figure into two: one describing the TLV containing one or more “elements” and one describing the fields used in each element.
<Shraddha> Yes. updated

5.       In Figure 6, the “No.of elements in set” field as well as the “No.of IPv6 interface pairs” field of the last element in the set seem a bit redundant since the information can be inferred from the “Length” and “No.of IPv4 interface pairs ” of the last element in the set fields
<Shraddha>Since both IPv4 and IPv6 addresses pairs may be present simultaneously, number of pairs field is required.

As for comment #3 above, this is ok for me but please add some text to clarify whether the receiver should/shall perform some validation check
 <shraddha> sure will add new section in next revision.
Italo

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: venerdì 14 febbraio 2020 05:53
> To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>>; Alexander
> Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; Sam Aldrin
> <aldrin.ietf@gmail.com<mailto:aldrin.ietf@gmail.com>>; Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>
> Cc: draft-hegde-mpls-spring-epe-oam@ietf.org<mailto:draft-hegde-mpls-spring-epe-oam@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>
> Subject: MPLS-RT review of draft-hegde-mpls-spring-epe-oam
>
> Mathew, Sam, Sasha and Italo,
>
> You have be selected as MPLS-RT reviewers for draft-hegde-mpls-spring-epe-
> oam.
>
> Note to authors: You have been CC'd on this email so that you can know that
> this review is going on. However, please do not review your own document.
>
> Reviews should comment on whether the document is coherent, is it useful (ie,
> is it likely to be actually useful in operational networks), and is the document
> technically sound?  We are interested in knowing whether the document is
> ready to be considered for WG adoption (ie, it doesn't have to be perfect at
> this point, but should be a good start).
>
> Reviews should be sent to the document authors, WG co-chairs and WG
> secretary, and CC'd to the MPLS WG email list. If necessary, comments may be
> sent privately to only the WG chairs.
>
> If you have technical comments you should try to be explicit about what
> *really* need to be resolved before adopting it as a working group document,
> and what can wait until the document is a working group document and the
> working group has the revision control.
>
> Are you able to review this draft by Feb 28, 2020? Please respond in a timely
> fashion.
>
>
> Thanks, Loa
> (as MPLS WG chair)
> --
> --
>
>
> Loa Andersson                        email: loa@pi.nu<mailto:loa@pi.nu>
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64