Re: [mpls] MPLS-RT for draft-wijnands-mpls-mldp-multi-topology

Tarek Saad <tsaad.net@gmail.com> Thu, 05 May 2022 19:22 UTC

Return-Path: <tsaad.net@gmail.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 8E613C1594AB; Thu, 5 May 2022 12:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfXizXs426g7; Thu, 5 May 2022 12:22:21 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0482C15949C; Thu, 5 May 2022 12:22:21 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id f2so5795895ioh.7; Thu, 05 May 2022 12:22:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=AsYiWS9Mppi2OptnkZYAZJTvd3dBLpzn+32xKMAmHEc=; b=MTgYTmL0fO4U/jb0PIdijRiaGwZd19e8e3XHW/w4VUWTumhtzg6tOYOV7+tonzOPmd gT2+IEX14KgCHILSpAhMiHYtE3dzzwAthlBikKve/CNEjgt/3IRQLRFjVFSndLv2v+E1 ZgXfKbvi8/11i7mwyq7rrX2CdExJgdYu9KjTXsCY/H/WCEMcAELM1ZpPIbgCgXUBgc/M c6lxwciUWi/YHSffe73F/s/FuC+DtjRXUq6rBQcivHKCoyt+WbhZs7etIm6XUkjNLwRk ZsEa/2/wO60uFIopQkyPaj+sRSy/42VsYqda5p0gJ/B+YFKlb5OyhYUKtWp9IbqJZjpj UKYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=AsYiWS9Mppi2OptnkZYAZJTvd3dBLpzn+32xKMAmHEc=; b=ZYLQLd8ANjfzsRrOvbnjIEOtAef550JeerZITQVsGk07qy70y/QdIZPBM8dE+GV8S7 ckj5m2IcLZ6KeGbAmQDRJ3/5+yJM5sMrXZQodfc2litEeD1sOIeDGqYWp5dIe7jQGgyF s+Msz6eEvvpEXXJ/TNyK0yxcPZd56Ohzlkopw+A18dGyulibVEbHfz/eDjZS2yoNDy7W 0BPdKEWpOT9Ud9761K71frF8j8NFsO6B7t3lnK+QJOzv0bOFWBKDo1s/ScZsynOH5dhO CKWjyMkhAS22GIYqF/vcau/6z6nWkk0k1YQBXj4nPs1VmOkmE64+Tzu33mhJdiCTjTCh tyIw==
X-Gm-Message-State: AOAM532X/44NQHSi2EvjvPk6uWcw+INPjC5iE14DnV68BMFgKjDpblX+ hkfhYKhHrd8sskdbxMo8vquNyMmYX5U+/Q==
X-Google-Smtp-Source: ABdhPJzCZ6AevwcPFS/e4hpcUoSXww8q2E8C9XmIPoCmNLVBlQtee/aSI7BCgKfaCrTVMg4GHkcpnQ==
X-Received: by 2002:a02:c887:0:b0:32a:fbd6:2e4c with SMTP id m7-20020a02c887000000b0032afbd62e4cmr12078411jao.244.1651778540372; Thu, 05 May 2022 12:22:20 -0700 (PDT)
Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([40.97.200.53]) by smtp.gmail.com with ESMTPSA id s22-20020a5eaa16000000b0065a47e16f54sm630202ioe.38.2022.05.05.12.22.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 May 2022 12:22:19 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: "wijnands-mpls-mldp-multi-topology@ietf.org" <wijnands-mpls-mldp-multi-topology@ietf.org>
CC: "mpls@ietf.org" <mpls@ietf.org>, MPLS Working Chairs <mpls-chairs@ietf.org>
Thread-Topic: MPLS-RT for draft-wijnands-mpls-mldp-multi-topology
Thread-Index: AQHX8DU10NQagzme3ESRwMpsL13qR6xDqayAgC7kP4CAAOApt4AA0emAgEJSyv6AFfEAYYBFBPSh
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 5 May 2022 19:22:15 +0000
Message-ID: <DM5PR1901MB215025B1B4826B30FF2FD759FCC29@DM5PR1901MB2150.namprd19.prod.outlook.com>
References: <DM5PR1901MB215088290DFB8D7AD0105628FC749@DM5PR1901MB2150.namprd19.prod.outlook.com> <CA+RyBmUzfw7vMsKKDHNDCf8+JfRxrbKV28S+UjwDm8SLh0Or9w@mail.gmail.com> <E5C78CBB-7CCE-4703-8775-487847FFE93E@cisco.com> <BYAPR11MB2725C6EC64F66878619D049CDF5F9@BYAPR11MB2725.namprd11.prod.outlook.com> <CA+RyBmVJKD6sBap8kiyg7zQSubDDP+pX-rFXE07BJgC6u=_GCA@mail.gmail.com> <BYAPR11MB272588F629458C3839EB63B6DF099@BYAPR11MB2725.namprd11.prod.outlook.com> <BYAPR11MB2725C61CAA25E5EC159C35E1DF179@BYAPR11MB2725.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB2725C61CAA25E5EC159C35E1DF179@BYAPR11MB2725.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-CA
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB215025B1B4826B30FF2FD759FCC29DM5PR1901MB2150_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/MXrDj33Jyc-8jYiMLF4RKEuKolA>
Subject: Re: [mpls] MPLS-RT for draft-wijnands-mpls-mldp-multi-topology
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.34
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: Thu, 05 May 2022 19:22:25 -0000

Hi WG,

The draft ID.wijnands-mpls-mldp-multi-topology has gone through a round of MPLS-RT review. The authors have indicated that they have addressed all outstanding comments received during the RT review and that the latest revision is ready to progress to adoption. The WG chairs will consider this and progress the document forward.

Regards,
Tarek (MPLS WG Co-Chair)

From: Mankamana Mishra (mankamis) <mankamis@cisco.com>
Date: Tuesday, March 22, 2022 at 5:18 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Anuj Budhiraja (abudhira) <abudhira@cisco.com>, Tarek Saad <tsaad.net@gmail.com>, Sergio Belotti <sergio.belotti@nokia.com>, Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, draft-wijnands-mpls-mldp-multi-topology@ietf.org <draft-wijnands-mpls-mldp-multi-topology@ietf.org>, MPLS Working Chairs <mpls-chairs@ietf.org>
Subject: Re: MPLS-RT for draft-wijnands-mpls-mldp-multi-topology
Chairs, Reviewers
We have updated the draft based on comment. Wanted to check if we could have adoption call for this.

Mankamana

From: Mankamana Mishra (mankamis) <mankamis@cisco.com>
Date: Tuesday, March 8, 2022 at 2:13 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Anuj Budhiraja (abudhira) <abudhira@cisco.com>, Tarek Saad <tsaad.net@gmail.com>, Sergio Belotti <sergio.belotti@nokia.com>, Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, draft-wijnands-mpls-mldp-multi-topology@ietf.org <draft-wijnands-mpls-mldp-multi-topology@ietf.org>, MPLS Working Chairs <mpls-chairs@ietf.org>
Subject: Re: MPLS-RT for draft-wijnands-mpls-mldp-multi-topology
Hi Greg,
We have addressed your comment and pushed new version. Please let me know if there is any other comment.

Mankamana

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tuesday, January 25, 2022 at 9:23 AM
To: Mankamana Mishra (mankamis) <mankamis@cisco.com>
Cc: Anuj Budhiraja (abudhira) <abudhira@cisco.com>, Tarek Saad <tsaad.net@gmail.com>, Sergio Belotti <sergio.belotti@nokia.com>, Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, draft-wijnands-mpls-mldp-multi-topology@ietf.org <draft-wijnands-mpls-mldp-multi-topology@ietf.org>, MPLS Working Chairs <mpls-chairs@ietf.org>
Subject: Re: MPLS-RT for draft-wijnands-mpls-mldp-multi-topology
Hi Mankamana,
yes, you're correct, that is, as far as I know, the practice (at least that is what I was doing and am suggesting to others). Although it might be a de-facto standard practice, stating it explicitly, in my opinion, seems like the right thing to do.

Regards,
Greg

On Mon, Jan 24, 2022 at 8:53 PM Mankamana Mishra (mankamis) <mankamis@cisco.com<mailto:mankamis@cisco.com>> wrote:
Hi Greg,
Thanks for catching and detail review . General question, should it not be practice to set all reserved fields to zero (at least BESS has practice I guess).  We will wait for your comment before submitting next version of draft.

Mankamana

From: Anuj Budhiraja (abudhira) <abudhira@cisco.com<mailto:abudhira@cisco.com>>
Date: Monday, January 24, 2022 at 3:29 PM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>, Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>
Cc: Sergio Belotti <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>, Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com<mailto:ahabdels@cisco.com>>, draft-wijnands-mpls-mldp-multi-topology@ietf.org<mailto:draft-wijnands-mpls-mldp-multi-topology@ietf.org> <draft-wijnands-mpls-mldp-multi-topology@ietf.org<mailto:draft-wijnands-mpls-mldp-multi-topology@ietf.org>>, MPLS Working Chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>
Subject: Re: MPLS-RT for draft-wijnands-mpls-mldp-multi-topology
Hi Greg,

Thank you for reviewing the draft and providing the comments.


  *   As I understand it, you propose re-using the Address Family identifiers IP MT and IPv6 MT defined in RFC 7307. It is an elegant way of adding the IP Algorithm parameter but I have a concern with interworking between MT Address Family FEC and Modified MT IP Address Family FEC. The modified format re-uses one octet of the two-octet Reserved field for IPA. I think it would work fine if the Reserved field was zeroed (usually implementors do that) but RFC 7307<https://datatracker.ietf.org/doc/html/rfc7307#section-3.2> doesn't define the handling of the Reserved field for MT Address Family FEC. It appears that it is possible that a node supporting the draft receives RFC7307-style FEC with a non-zero value. Do you think there's a potential problem?
Yes, it’s going to be a problem. If any of the existing implementations of RFC 7307 use the Reserved field with first 8 bits as zero and last 8 bits between any valid Flex Algorithm value (128 – 255) then the FECs will collide with the draft implementations. One way to address this issue is this draft updates the RFC 7307.


  *   The handling of the Reserved field in Section 4.1.2 is defined as follows:
      Reserved: This 8-bit field MUST be zero.  If a message is received that includes a MT address family where the 8 bit Reserved value is not zero, the message must be discarded.
Usually, the value of the Reserved field is ignored on the receipt. I am curious about why you require the message to be discarded if the value is non-zero.
You are right, this needs to be corrected. Reserved field SHOULD be zero not MUST and message shouldn’t be discarded on receiving non-zero value.

Thanks,
Anuj

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Saturday, December 25, 2021 at 11:25 AM
To: Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>
Cc: Sergio Belotti <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>, "Ahmed Abdelsalam (ahabdels)" <ahabdels@cisco.com<mailto:ahabdels@cisco.com>>, "draft-wijnands-mpls-mldp-multi-topology@ietf.org<mailto:draft-wijnands-mpls-mldp-multi-topology@ietf.org>" <draft-wijnands-mpls-mldp-multi-topology@ietf.org<mailto:draft-wijnands-mpls-mldp-multi-topology@ietf.org>>, MPLS Working Chairs <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>
Subject: Re: MPLS-RT for draft-wijnands-mpls-mldp-multi-topology
Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent-To: <skraza@cisco.com<mailto:skraza@cisco.com>>, <zzhang@juniper.net<mailto:zzhang@juniper.net>>, <ice@braindump.be<mailto:ice@braindump.be>>, Anuj Budhiraja <abudhira@cisco.com<mailto:abudhira@cisco.com>>, Mankamana Mishra <mankamis@cisco.com<mailto:mankamis@cisco.com>>, <arkadiy.gulko@edwardjones.com<mailto:arkadiy.gulko@edwardjones.com>>
Resent-Date: Saturday, December 25, 2021 at 11:24 AM

Dear Authors, et al,
firstly, Happy Holidays to All!
Secondly, I've read the draft. It is well-written, addresses the real problem, and proposes practical solutions to it. Thank you for your work!
I have a couple of notes and appreciate your consideration:

  *   As I understand it, you propose re-using the Address Family identifiers IP MT and IPv6 MT defined in RFC 7307. It is an elegant way of adding the IP Algorithm parameter but I have a concern with interworking between MT Address Family FEC and Modified MT IP Address Family FEC. The modified format re-uses one octet of the two-octet Reserved field for IPA. I think it would work fine if the Reserved field was zeroed (usually implementors do that) but RFC 7307<https://datatracker.ietf.org/doc/html/rfc7307#section-3.2> doesn't define the handling of the Reserved field for MT Address Family FEC. It appears that it is possible that a node supporting the draft receives RFC7307-style FEC with a non-zero value. Do you think there's a potential problem?
  *   The handling of the Reserved field in Section 4.1.2 is defined as follows:
      Reserved: This 8-bit field MUST be zero.  If a message is received
      that includes a MT address family where the 8 bit Reserved value
      is not zero, the message must be discarded.
Usually, the value of the Reserved field is ignored on the receipt. I am curious about why you require the message to be discarded if the value is non-zero.

Regards,
Greg

On Mon, Dec 13, 2021 at 7:22 AM Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> wrote:
Hi Sergio/Greg/Ahmed,
You have been selected as potential MPLS-RT reviewers for draft-wijnands-mpls-mldp-multi-topology-03.
Note to authors: You have been CC'd on this email so that you can know that this review is going on.
Reviews should comment on whether the document is coherent, is it useful (i.e., 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).
Please send reviews to the document authors, WG co-chairs and WG secretary, and CC 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.
Can you do this review of the document by January 3, 2022?
Regards,
Tarek (as MPLS WG chair)