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

Italo Busi <Italo.Busi@huawei.com> Wed, 26 February 2020 16:59 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 D17CB3A0BBB; Wed, 26 Feb 2020 08:59:53 -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, 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 zhENoR0tM7Nn; Wed, 26 Feb 2020 08:59:50 -0800 (PST)
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 DD7E53A0B90; Wed, 26 Feb 2020 08:59:49 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A273EBE5B3CB481C8C52; Wed, 26 Feb 2020 16:59:47 +0000 (GMT)
Received: from fraeml718-chm.china.huawei.com (10.206.15.14) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 26 Feb 2020 16:59:46 +0000
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml718-chm.china.huawei.com (10.206.15.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 26 Feb 2020 17:59:46 +0100
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.1713.004; Wed, 26 Feb 2020 17:59:46 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: "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/ts0EbuOkuowWYDGxi83agtpLqg
Date: Wed, 26 Feb 2020 16:59:46 +0000
Message-ID: <5aa73bfd247040d4bae8131f4eb43b5f@huawei.com>
References: <2141e262-752f-0c7e-fdcb-03aea45e9aa1@pi.nu>
In-Reply-To: <2141e262-752f-0c7e-fdcb-03aea45e9aa1@pi.nu>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.220.132.232]
Content-Type: multipart/alternative; boundary="_000_5aa73bfd247040d4bae8131f4eb43b5fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/vaU7WzmHK0idQW4IUbyjC8SaGOw>
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: Wed, 26 Feb 2020 16:59:54 -0000

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.

   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.

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.

   It would be worthwhile to reference draft-ietf-idr-bgpls-segment-routing-epe for these definitions.

   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)

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

   This is ok for me but please add some text to clarify whether the receiver should/shall perform some validation check

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.

   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.

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

   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

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>om>; Alexander
> Vainshtein <Alexander.Vainshtein@ecitele.com>om>; Sam Aldrin
> <aldrin.ietf@gmail.com>om>; Italo Busi <Italo.Busi@huawei.com>
> Cc: draft-hegde-mpls-spring-epe-oam@ietf.org; 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