Re: [RTG-DIR] [mpls] [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13
Alex Bogdanov <bogdanov@google.com> Mon, 19 November 2018 18:47 UTC
Return-Path: <bogdanov@google.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A6D130E13 for <rtg-dir@ietfa.amsl.com>; Mon, 19 Nov 2018 10:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.491
X-Spam-Level:
X-Spam-Status: No, score=-17.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Uvx6Ubiw3P6C for <rtg-dir@ietfa.amsl.com>; Mon, 19 Nov 2018 10:47:31 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFF4130DFE for <rtg-dir@ietf.org>; Mon, 19 Nov 2018 10:47:23 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id p74so18427199vsc.0 for <rtg-dir@ietf.org>; Mon, 19 Nov 2018 10:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g2DWToyU9PH43kTSmOE/nRrWSLBi/7M9TGnvNFq+1iw=; b=kfflTTkxatjCczBjog18DKy/hiXJ2j/+bDuXCYXqaSrhSJ4IcJT6EZZIgdQC8ksS93 J6C2jhPOtfEGjCkADya5IotgUtDRjR5Za1erCPLxkTEImlMMwXqN8Q2K/93m1CqnjYZK k300xLJO95NoiywkqwP0Gw1BuRgnIJOSw0BUzLw1bgFQwI0bEANb87ebNdL5lBs0/qqe AjPk2YvLsfALcrGapDc8ZkYGmh6j15WqSYNiv8F7sN67IDRBV3LkNlVZIJVK3F+xkmVZ zXC/HnJBpfGfXDzMIlN55Lcs6/QzQ4JXl+uQeghdddY0a25LVCRLPUw9sus70L6uuLmP Q09A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g2DWToyU9PH43kTSmOE/nRrWSLBi/7M9TGnvNFq+1iw=; b=s+9CYxLN4UzPp7ppCBs941IccPgTRnv743roGtGk2+lyZOOO5hy2F8/vFeTVzgKycu EqtcHLpqZiTY9l/ZtYlfmKYhXTw0MwNEmWW50HihZUe1hv2A5XLfeTayM3+7ZwWHxd10 pPkfQ6lcI88jpx7etDvrR5b/YpwS3+jMvesGhxo/3KTp7lsz6eoJb9L9XjJi71+IQXmk 07cKkDXc+JO8ctCMIClcRjCn0CNtliJNvqRtbOCyxV2kMRZ30PRNEyzmC2eVcGTLG+7G 7V6U0bT1/ZaDLD9R2CXeoBQl5zX2WbxOA4+r+wLQFlL4TASlWynGpAM6qDFEA7x8DQ0b hl/A==
X-Gm-Message-State: AGRZ1gKZi5TXkXEbNOQyPVR6D2p/MHbdTA3e4n9ews5U2Ob+immQbbCd ZWApxtWnCU3qj3VErVOcd8MRuvixsAjYzlpd4jWs3A==
X-Google-Smtp-Source: AJdET5fsQzeDPxQjldhqR1fo8eY+XzQxFKNiA5oio4N49iTpWZRLDhRX9+wRGFQqT419BSh1z+l4OSI26N/C+gdq4PE=
X-Received: by 2002:a67:2309:: with SMTP id v9mr9737667vsf.115.1542653241991; Mon, 19 Nov 2018 10:47:21 -0800 (PST)
MIME-Version: 1.0
References: <DB5PR0301MB19093D3B7D8159B9A341F5F79D790@DB5PR0301MB1909.eurprd03.prod.outlook.com> <DB5PR0301MB190932C9A74DE438278C337D9D730@DB5PR0301MB1909.eurprd03.prod.outlook.com> <46a64bb1-1b17-184c-1089-e05315057236@gmail.com> <DB5PR0301MB1909C7F93AA4DF7CFB5EEEA09D5A0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <DB5PR0301MB19090AA4E888EFF6E634B4239D590@DB5PR0301MB1909.eurprd03.prod.outlook.com> <da7c2afe-ebf8-1827-1134-14f72044c812@gmail.com> <DB5PR0301MB1909542DB5C8F571257304929D520@DB5PR0301MB1909.eurprd03.prod.outlook.com> <BN3PR05MB27060F2C9F0D775C33AD5A65D5510@BN3PR05MB2706.namprd05.prod.outlook.com> <c33105ce-41b2-3beb-f8d7-826999a8f588@gmail.com> <DB5PR0301MB1909D4AB682398BD152E72519DC90@DB5PR0301MB1909.eurprd03.prod.outlook.com> <BYAPR05MB3943FB07ACA7E343152F2BFBD5D80@BYAPR05MB3943.namprd05.prod.outlook.com> <CACH2EkUXjNDJs2rDtAZ5OiMCbAdknvoHcUx3AtMcHatG_jdEjQ@mail.gmail.com>
In-Reply-To: <CACH2EkUXjNDJs2rDtAZ5OiMCbAdknvoHcUx3AtMcHatG_jdEjQ@mail.gmail.com>
From: Alex Bogdanov <bogdanov@google.com>
Date: Mon, 19 Nov 2018 10:47:09 -0800
Message-ID: <CA+q+MpXOSwzOhEP_hf5CGqBFb0=avFNQmYZZdgnEv_uFAfwV4g@mail.gmail.com>
To: Przemyslaw Krol <pkrol=40google.com@dmarc.ietf.org>
Cc: Shraddha Hegde <shraddha@juniper.net>, rtg-dir@ietf.org, spring@ietf.org, mpls@ietf.org, spring-chairs@ietf.org, jonathan.hardwick@metaswitch.com, draft-ietf-spring-segment-routing-mpls.authors@ietf.org
Content-Type: multipart/alternative; boundary="00000000000080b26d057b08f282"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/Ph2ePf7aRTQI2UCr6h6Dt0k4v64>
Subject: Re: [RTG-DIR] [mpls] [spring] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 18:47:43 -0000
Hello Shraddha, I think it's an important recommendation to include. In the absence of another obvious draft/RFC, I would lean towards my original proposal of including it as a section in draft-ietf-spring-segment-routing-mpls. Cheers, Alex On Mon, Nov 19, 2018 at 8:02 AM Przemyslaw Krol <pkrol= 40google.com@dmarc.ietf.org> wrote: > Hi Shraddha > > I think this would be very helpful. > > pk > > On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde <shraddha@juniper.net> > wrote: > >> Hi all, >> >> >> >> I am preparing the shepherd write-up and noticed that the topic in below >> e-mail thread is an >> >> Open item. My personal opinion is to add a new section to this draft to >> address below cases >> >> > more than one node advertising the same IPv4/6 PREFIX and both have >> the same prefix-SID value with "N" flag >> >> > where an anycast prefix is advertised with a prefix-SID sub-TLV by >> some (but not all) of the nodes that advertise that prefix. >> >> >> >> This draft is addressing incoming label collision and resulting behavior >> and also describes other aspects like different SIDs for same prefix so it >> seems reasonable to add above two cases to this draft. >> >> WG members, if you have an opinion, pls respond on the list. >> >> >> >> Rgds >> >> Shraddha >> > *From:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> >> > *Sent:* Sunday, November 4, 2018 9:37 PM >> *To:* Ahmed Bashandy <abashandy.ietf@gmail.com> >> > *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; ' >> adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; >> spring@ietf.org; spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf..org; Shraddha Hegde >> <shraddha@juniper.net> >> > >> *Subject:* RE: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> > >> >> Ahmed, >> >> Apologies for a delayed response. >> >> I fully agree that advertising the same prefix SID as the Node SID by two >> different nodes in the SR domain is “a clear violation of the SR >> architecture RFC (8402)”. >> >> But I do not think that the SR-MPLS draft can silently ignore this >> violation just because it “is not an incoming label collision”. >> >> The same applies to the controversy in advertising at the same prefix as >> Anycast by some nodes but not as Anycast (or even as a Node SID) by some >> other nodes. >> >> Your reference to these being just control plane issues and therefore not >> related to SR-MPLS is not valid - because the drafts dealing with the SR >> control plane to which you refer in this draft are strictly MPLS-oriented: >> they define how to advertise *SID labels* or *indices* that are >> translated into *SID labels*, and neither of these mechanisms is >> relevant fore SRV6 IMHO. (I do not have to remind you that a draft that >> defines SRV6 extensions for ISIS >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbashandy-2Disis-2Dsrv6-2Dextensions_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=ko-3eF8yySF1exH64SoeyEP0ett4gjsHmmOCvj9zCvQ&s=_AZSiqmTUTMKFS9DAqboueo_GnvvAcFxARWF820HnTA&e=> >> exists, and deals with other issues). >> >> My 2c, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Ahmed Bashandy [mailto:abashandy.ietf@gmail.com >> <abashandy.ietf@gmail.com>] >> *Sent:* Sunday, October 28, 2018 1:01 AM >> *To:* Shraddha Hegde <shraddha@juniper.net>; Alexander Vainshtein < >> Alexander.Vainshtein@ecitele.com> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; ' >> adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; >> spring@ietf.org; spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> *Subject:* Re: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> >> >> Thanks for the comments >> >> While it is a clear violation of the SR architecture RFC (8402), more >> than one node advertising the same IPv4/6 PREFIX and both have the same >> prefix-SID value with "N" flag is not an incoming label collision because >> the label is associated with the same FEC, which is the prefix. >> >> Hence handling such violation is not an SR-MPLS problem because there is >> no incoming label collision and hence it it is outside the scope of this >> draft >> >> >> >> The second issue is which SID to choose for an SR-policy (be it a policy >> for TE, ti-lfa, uloop avoidance, security,..., etc). That is strictly a >> control layer functionality and is not specific to SR-MPLS. Hence it is >> outside the scope of this draft >> >> >> >> The third issue is the case where an anycast prefix is advertised with a >> prefix-SID sub-TLV by some (but not all) of the nodes that advertise that >> prefix. Again this is not an incoming label collision because the label is >> associated with a single FEC, which is the anycast prefix. >> >> >> >> On 7/19/18 8:30 PM, Shraddha Hegde wrote: >> > Hi Ahmed, >> >> >> >> The Node-SIDs are expected to be unique to a node. >> >> “ >> >> An IGP Node-SID MUST NOT be associated with a prefix that is owned by >> >> more than one router within the same routing domain.” >> >> >> >> If two different nodes advertise same Node-SID, >> >> For Example Node A and B both advertise prefix 1.1.1.1 and >> associate a SID 1000 with N bit set. >> >> There is an anomaly here and IMO, this draft should address how to handle >> this anomaly and whether TI-LFA and other >> >> Applications can use this SID as a Node-SID. >> >> Another slight variation of this case is a scenario where A and B both >> advertise a prefix 1.1.1.1 and A assigns a Node-Sid >> >> Of 1000 and B does not assign any SID. >> >> >> >> Rgds >> >> Shraddha >> >> >> >> *From:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> >> <Alexander.Vainshtein@ecitele.com> >> *Sent:* Thursday, July 19, 2018 10:05 PM >> *To:* Ahmed Bashandy <abashandy.ietf@gmail.com> >> <abashandy.ietf@gmail.com> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org> <mpls@ietf.org>; >> 'adrian@olddog.co.uk' <adrian@olddog.co.uk> <adrian@olddog.co.uk>; >> Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) >> <jonathan.hardwick@metaswitch.com> <jonathan.hardwick@metaswitch.com>; >> Shraddha Hegde <shraddha@juniper.net> <shraddha@juniper.net>; >> spring@ietf.org; spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> *Subject:* RE: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> >> >> Ahmed hi! >> >> Lots of thanks for your response. >> >> Of course Node SIDs are not different from any other Prefix SIDs when it >> comes to the MPLS forwarding plane. >> >> But, IMHO, strictly speaking, this is correct for any other SID as well. >> >> You seem to ignore the difference between SR-MPLS and SRv6 with regard to >> the life span of prefix SIDs in general and Node SIDs in particular. From >> my POV this difference should be discussed in the draft. >> >> So it seems that we can only “agree to disagree” on the need to say >> something specific about Node SIDs in the draft, and let the WG to decide >> what to do about it. >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Ahmed Bashandy [mailto:abashandy.ietf@gmail.com >> <abashandy.ietf@gmail.com>] >> *Sent:* Thursday, July 19, 2018 7:13 PM >> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; ' >> adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; >> shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> *Subject:* Re: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> >> >> Thanks for the reply >> >> See inline >> >> Ahmed >> >> >> >> On 7/12/18 12:22 AM, Alexander Vainshtein wrote: >> >> Ahmed and all, >> >> I would like to expand on my comments (and your responses) about the role >> of Node SIDs in SR-MPLS. >> >> I would like to bring your attention two points: >> >> 1. Node SIDs (and, in general, Prefix SIDs) in MPLS-SR are >> different from the same in SRv6 because they require explicit configuration >> action by the operator of SR domain. I.e., it is not enough for a node to >> own some /32 or /128 prefix that is advertised by IGP. The operator must >> explicitly configure the node to use such a prefix as Node SID and to >> assign to it a specific index that is unique in the SR domain. From my POV, >> this difference alone would qualify Node SIDs as a topic to be discussed in >> the MPLS-SR Architecture >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls-2D14&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=q6djpRXlamUzKZlGIuXTtBcsnwevHwddqvStZrSFMnE&e=> >> draft. >> >> #Ahmed: I disagree with your POV. From the forwarding plane perspective >> it does not make any difference whether a the label at the top of an MPLS >> packet (representing the prefix-SID) identifies a node or not. So from the >> SR-mpls forwarding point of view there is no difference between a >> prefix-SID and a node-SID. If there is any place in the SR-mpls draft where >> there is a need to handle a node-SID different from a prefix SID, it would >> be great to point it out >> >> 2. In addition, quite a few constructs associated with SR-MPLS >> implicitly assume that each node in the SR-MPLS domain is assigned with at >> least one Node SID. One example can be found in the TI-LFA >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=> >> draft. This draft says in Section 4.2: >> >> >> >> 4.2 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04-23section-2D4.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=sAi3KCWUwGS3D93t8ic64W_46xm9y8Oacs7ozcAweS8&e=>.. >> The repair node is a PQ node >> >> >> >> >> >> When the repair node is in P(S,X), the repair list is made of a >> >> single node segment to the repair node. >> >> In the scope of this section, the repair node is not adjacent to the PLR, >> and therefore, to the best of my understanding, “a single node segment >> to the repair node” can be only the Node SID of the repair node. Since >> repair nodes are computed dynamically, this entire scheme depends on all >> nodes in the MPLS=SR domain having at least one Node SID each >> >> #Ahmed: The choice of the SID to identify an intermediate or exit node(s) >> in an SR-policy is a control plane behavior, irrespective of reason such >> policy is created (be it ti-lfa explicit path, uloop avoidance explicit >> path, or some SR-TE explicit path). SR-Policy as well as Ti-LFA and uloop >> avoidance are handled in separate drafts. So just like the response to your >> previous comment, from forwarding plane perspective it does not make any >> difference whether the label at the top of an MPLS packet identifies a >> single or multiple nodes. >> >> . >> >> >> >> Hopefully these notes clarify my position on the subject. >> >> >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Alexander Vainshtein >> *Sent:* Wednesday, July 11, 2018 12:02 PM >> *To:* Ahmed Bashandy <abashandy.ietf@gmail.com> >> <abashandy.ietf@gmail.com> >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org> <mpls@ietf.org>; >> 'adrian@olddog.co.uk' <adrian@olddog.co.uk> <adrian@olddog.co.uk>; >> Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) >> <jonathan.hardwick@metaswitch.com> <jonathan.hardwick@metaswitch.com>; >> shraddha@juniper.net; spring@ietf.org; spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> *Subject:* RE: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> >> >> Ahmed, and all, >> >> Lots of thanks for a detailed response to my comments. >> >> Please see *inline below* my position on each of them. >> >> >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Ahmed Bashandy [mailto:abashandy.ietf@gmail.com >> <abashandy.ietf@gmail.com>] >> *Sent:* Wednesday, July 11, 2018 4:42 AM >> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; >> spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> *Cc:* rtg-dir@ietf.org; 'mpls@ietf.org' <mpls@ietf.org>; ' >> adrian@olddog.co.uk' <adrian@olddog.co.uk>; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com) <jonathan.hardwick@metaswitch.com>; >> shraddha@juniper.net; spring@ietf.org >> *Subject:* Re: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> >> >> Thanks for thorough (and VERY clear) the review >> >> See inline #Ahmed >> >> >> >> Ahmed >> >> >> >> >> >> On 6/15/18 11:08 PM, Alexander Vainshtein wrote: >> >> Re-sending to correct SPRING WG list. >> >> Sincere apologies for the delay caused by a typo. >> >> Thumb typed by Sasha Vainshtein >> >> >> ------------------------------ >> >> *From:* Alexander Vainshtein >> *Sent:* Sunday, June 10, 2018 10:43:52 AM >> *To:* spring-chairs@ietf.org; >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org >> >> *Cc:* spring@ietf..com <spring@ietf.com>; rtg-dir@ietf.org; ' >> mpls@ietf.org'; 'adrian@olddog.co.uk'; Jonathan Hardwick ( >> Jonathan.Hardwick@metaswitch.com); shraddha@juniper.net >> >> >> *Subject:* RE: RtgDir Early review: >> draft-ietf-spring-segment-routing-mpls-13 >> >> Explicitly adding Shraddha who is the shepherd of this draft. >> >> >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> *From:* Alexander Vainshtein >> *Sent:* Friday, June 8, 2018 5:43 PM >> *To:* 'spring-chairs@ietf.org' <spring-chairs@ietf.org> >> <spring-chairs@ietf.org>; ' >> draft-ietf-spring-segment-routing-mpls.authors@ietf.org' >> <draft-ietf-spring-segment-routing-mpls.authors@ietf.org> >> <draft-ietf-spring-segment-routing-mpls.authors@ietf.org> >> *Cc:* 'spring@ietf.com' <spring@ietf.com> <spring@ietf.com>; >> rtg-dir@ietf.org; mpls@ietf.org; 'adrian@olddog.co.uk' >> <adrian@olddog.co.uk> <adrian@olddog.co.uk> >> *Subject:* RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13 >> >> >> >> >> >> Hello, >> >> I have been selected to do a routing directorate “early” review of this >> draft: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=Cxbaaf9U0kj6_meVSobSkRLQW1SwI8MJvgHpuYp0QOM&e=> >> >> >> >> The routing directorate will, on request from the working group chair, >> perform an “early” review of a draft before it is submitted for publication >> to the IESG. The early review can be performed at any time during the >> draft’s lifetime as a working group document. The purpose of the early >> review depends on the stage that the document has reached. As this document >> is currently in the WG Last call, my focus for the review was to determine >> whether the document is ready to be published. Please consider my comments >> along with the other working group last call comments. >> >> >> >> For more information about the Routing Directorate, please see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=6pnI7l82ewwzoxgOXqTKrbKuQidt6-KBsZdsXFnoQCg&e=> >> >> >> >> *Document*: draft-ietf-spring-segment-routing-mpls-13 >> >> *Reviewer*: Alexander (“Sasha”) Vainshtein ( >> alexander.vainshtein@ecitele.com) >> >> *Review Date*: 08-Jun-18 >> >> *Intended Status*: Proposed Standard. >> >> >> >> *Summary*: >> >> >> >> I have some minor concerns about this document that I think should be >> resolved before it is submitted to the IESG. >> >> >> >> *Comments*: >> >> >> >> I consider this draft as an important companion document to the Segment >> Routing Architecture >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D15&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=iJShh7e7yyVkt44v1O5pyCOMfHCpAvfBNGgFr5lk130&e=> >> draft that, ideally, should augment definitions of the Segment Routing (SR) >> notions and constructs given there with details specific for the SR >> instantiation that uses the MPLS data plane (SR-MPLS). Many issues raised >> in my review reflect either gaps that should be, but have not been, closed, >> or inconsistencies between the two drafts. >> >> >> >> >> >> Since RFC 8287 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8287&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=y7jp3UYNTtcmm9HOulzqPTrMURTrsMiO26rWlNZN5Ws&e=> >> is already published as a Standards Track RFC, I expect such augmentation >> to be backward compatible with this document (or to provide clear >> indications of required updates to this document). And I include the MPLS >> WG into distribution list. >> >> >> >> This draft was not easy reading for me. In particular, the style of >> Section 2.5 that discusses at length and in some detail multiple “corner >> cases” resulting, presumably, from misconfiguration, before it explains the >> basic (and relatively simple) “normal” behavior, looks problematic to me. >> >> >> >> The WG Last Call has been extended by one week. Nevertheless, I am >> sending out my comments >> >> >> >> *Major Issues*: None found >> >> #Ahmed: thanks a lot >> >> >> >> *Minor Issues*: Quite a few but, hopefully, easy to resolve. >> >> >> >> 1. *Encapsulation of SR-MPLS packets*: >> >> a. RFC 3032 (referenced by the draft) and RFC 5332 (*not mentioned in >> the draft*) depend two encapsulations of labeled packets - one for >> Downstream-allocated labels and another for Upstream-allocated ones. >> >> #Ahmed: RFC5332 is for multicast. As mentioned in Section 6 of >> draft-ietf-spring-segment-routing-15, multicast is outside the scope of SR. >> Hence the RFC was not referred to in the SR-MPLS draft >> >> *[[Sasha]] I would be satisfied with this response, would it not be for >> the following text I see in Section 2.2 of the* *SR Policy Architecture* >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dpolicy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=4f0H68LTvkp7N-bYTVLOhWqiEbHaCsOQR1z_Qzz3Wf4&e=> >> *draft:* >> >> A variation of SR Policy can be used for packet replication. A >> >> candidate path could comprise multiple SID-Lists; one for each >> >> replication path. In such a scenario, packets are actually >> >> replicated through each SID List of the SR Policy to realize a point- >> >> to-multipoint service delivery. >> >> >> >> *This looks to me as being very much multicast in SR, and, unless you >> want to say that it is limited to SRv6, makes my question relevant IMHO.* >> >> b. From my POV the ST-MPLS only uses Downstream-allocated labels – >> but I expect the draft to state that explicitly, one way or another. (If >> Upstream-allocated labels are relevant for SR-MPLS, I would see it as a >> major gap, so I hope that this is not the case). >> >> #Ahmed: I will add a statement in section 2.2 to mention that it is >> down-stream allocated as you mentioned >> >> *[[Sasha]] This is quite unambiguous and, once added, would resolve my >> comment in full – the previous comment notwithstanding. In particular, it >> would imply that even labels representing BSIDs of a SR Replication >> policies will be downstream-allocated. * >> >> >> >> 2. *Label spaces in SR-MPLS*: >> >> a. RFC 3031 (referenced by the draft) defines per-platform and >> per-interface label spaces, and RFC 5331 (*not mentioned in the draft*) >> adds context-specific label spaces and context labels. >> >> b. The draft does not say which of these are or are not relevant for >> SR-MPLS >> >> c. From my POV: >> >> i. Labels representing all >> kinds of SIDs mentioned in the draft MUST be allocated from the >> per-platform label space only >> >> ii. At the same time, >> instantiation of Mirror Segment IDs defined in Section 5.1 of the Segment >> Routing Architecture draft using MPLS data plane clearly calls for context >> labels and context-specific label spaces >> >> d. I expect the draft to provide a clear-cut position on these >> aspects of SR-MPLS. >> >> #Ahmed: I will add a statement to section 2.2 to say that the it is >> per-platform. Regarding the function "mirroring", SR attaches a *function* >> to each SID. The "mirroring" function is already described in Section 5.1 >> of draft-ietf-spring-segment-routing and is not specific to the MPLS >> forwarding plane. Hence there is no need to re-mention it here because this >> document is trying to be as specific as possible to the MPLS forwarding >> plane. General functions attached to SID are described in the segment >> routing architecture document or future documents. Furture documents >> proposing new SR function must be as specific and clear as possible >> >> *[[Sasha]] Looks OK to me.* >> >> >> >> 3. *SR-MPLS and hierarchical LSPs*: >> >> a. SR LSPs that include more than one segment are hierarchical LSPs >> from the POV of the MPLS data plane. Therefore some (possibly, all) of the >> models for handling TTL and TC bits that have been defined in RFC 3443 (*not >> mentioned in the draft*) should apply to SR-MPLS >> >> b. RFC 8287 (*not referenced in the draft*) specifically discussed >> operation of the LSP Traceroute function for SR LSPs in the case when >> Pipe/Short Pipe model for TTL handling is used >> >> c. I expect the draft to provide at least some guidelines regarding >> applicability of each specific model defined in RFC 3443 (separately for >> TTL and TC bits) to SR-MPLS. >> >> #Ahmed: BY design, the instantiation of SR over the MPLS forwarding plane >> (and hence this draft) does not modify the MPLS forwarding plan behavior as >> it is mentioned in the first sentence in Section 1. So the TTL behavior >> specified in rfc3443 is already implied and there is no need to re-mention >> it here just like all aspects of MPLS forwarding. RFC8287 is OAM-specific. >> SR-OAM is handled in a separate document so is outside the scope of this >> draft >> >> *[[Sasha]] Unfortunately I do not think this is good enough. Let me ask a >> specific question reflecting my concerns:* >> >> *The head-end node sends SR-MPLS packets across a path defined by an >> ordered set of SIDs with more than one SID in the list. Each SID is >> represented by a label stack entry (LSE) in the MPLS label stack, and the >> label field in each LSE is the label that matches the corresponding SID. >> However, each LSE also includes the TTL and TC fields. How does the >> head-end node set these fields in each of the LSEs following the top one? >> This clearly depends on the model (Uniform vs. Pipe/Short Pipe) implemented >> in each node that that performs Next operation on the packet along the path >> – but the head-end node usually is not aware of that. * >> >> *RFC 8287 is relevant as an example here IMHO because it recommends the >> following setting of TTL in Traceroute packets:* >> >> - *Set the TTL of all the labels above one that represents the >> segment you are currently tracing to maximum* >> >> - *Set the TTL of the label one that represents the segment you >> are currently tracing to the desired value (to be incremented until end of >> segment is reached* >> >> - *Set the TTL of all the labels below one that represents the >> segment you are currently tracing to 0.* >> >> *I expect the draft to provide some recommendations for traffic (non-OAM) >> packets as well.* >> >> >> >> 4. *Inferring network layer protocol in SR-MPLS*: >> >> a. I wonder if the draft could provide any details on the situation >> when a label that represents some kind of SID is the bottom-of-stack label >> to be popped by the egress LER >> >> #ahmed: This is part of the "Next" function. It is described in detail in >> this document. >> >> *[[Sasha]] NEXT function is mentioned in several places in the document. >> Can you please point to the specific text that is relevant for my question?* >> >> >> >> b. For the reference, RFC 3032 says that “the identity of the network >> layer protocol must be inferable from the value of the label which is >> popped from the bottom of the stack, possibly along with the contents of >> the network layer header itself” >> >> c. From my POV the following scenario indicates relevance of this >> expectation for SR-MPLS: >> >> i. IS-IS is used for >> distributing both IPv4 and IPv6 reachability in a given domain >> >> ii. An IS-IS adjacency over >> some dual-stack link is established, and a single Adj-SID for this >> adjacency is advertised >> >> iii. The node that has >> assigned and advertised this Adj-SID receives a labeled packet with the >> label representing this Adj-SID being both the top and bottom-of-stack label >> >> iv. The implementers must be >> given unambiguous instructions for forwarding the unlabeled packet via the >> dual-stack link as an Ipv4 or an IPv6 packet. >> >> #Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and SR-OSFv3 >> drafts, you will see all 3 protocol advertise different adj-SIDS for IPv4 >> next-hop and IPv6 next-hop. For example, ISIS uses the "F-Flag" (section >> 2.2.1 in draft-ietf-isis-segment-routing-extensions-18) to specify whether >> the adj-SID is for IPv4 and IPv6. Similarly, the SR-ISIS draft attaches a >> prefix-SID to the prefix advertisement and hence implies the identity of >> the protocol underneath the bottom most label. For any other "function" >> attached to a SID, it is part of the specification of this function to >> describe what happens when the SID is represented by a label in the MPLS >> forwarding plane and this label is the bottom most label >> >> *[[Sasha]] OK, got it. This issue is resolved.* >> >> >> >> 5. *Resolution* *of Conflicts*: Are the >> >> a. Are the conflict resolution procedures listed in section 2.5 >> mandatory to implement? >> >> b. If they are mandatory to implement, are they also mandatory to >> deploy, or can the operators simply treat any detected conflict as >> requiring human intervention and preventing normal operation of SR-MPLS? >> >> #Ahmed: They are recommended. I will modify the paragraph after the first >> 3 bullets in Section 2.5 to say that it is recommeded. >> >> *[[Sasha]] OK. However, it would be nice if you could refer separately >> for “RECOMMENDED to implement” and “RECOMMENDED to deploy”. The latter >> probably requires a configuration knob for enabling conflict resolution >> rules (if they are implemented). * >> >> c. For the reference, the IETF capitalized MUST appears just in a few >> places in Section 2.5, and each appearance has very narrow context: >> >> i. For MCCs where the >> "Topology" and/or "Algorithm" fields are not defined, the numerical value >> of zero MUST be used for these two fields >> >> ii. If the same set of FECs >> are attached to the same label "L1", then the tie-breaking rules MUST >> always select the same FEC irrespective of the order in which the FECs and >> the label "L1" are received. In other words, the tie-breaking rule MUST be >> deterministic. >> >> iii. An implementation of >> explicit SID assignment MUST guarantee collision freeness on the same router >> >> From my POV, it is not possible to infer the answer to my question from >> these statements. Some explicit statement is required. >> >> #Ahmed: I agree with you POV and as mentioned in my reply to items (a) >> and (b), I will modify the paragraph to say that it is RECOMMENDED to >> answer you questions in items (a) and (b) >> >> d. The tie-breaking rules in section 2.5.1 include some specific >> values for encoding FEC types and address families – but these values are >> not supposed to appear in any IANA registries (because the draft does not >> request any IANA actions). Can you please clarify what is so special about >> these values? >> >> #Ahmed: There is no significance to the values but there is a >> significance to the order among them. I will modify the text to clarify that >> >> *[[Sasha]] OK. * >> >> >> >> e. I also doubt that comparison of FECs that represent IPv4 and IPv6 >> prefix SIDs makes much sense (for conflict resolution or else), because, >> among other things, there are valid scenarios when an IPv4 /32 prefix is >> embedded in an IPv6 /128 one. >> >> #Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix that embeds >> an IPv4 prefix is different from the IPv4 prefix. The specifications of SR >> extensions to ISIS, OSPFv2, OSPFv3, and BGP treat IPv4 and IPv6 prefixes >> separately, including the IPV6 prefixes with embedded IPv4 ones. Besides >> not all IPv6 prefixes embed IPv4 prefix in them. Hence the distinction >> between IPv4 and IPv6 prefixes is quite clear >> >> *[[Sasha]] My concern was mainly about IPv4-mapped IPv6 addresses. >> Quoting from RFC 4291:* >> *2.5.5.2* >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools..ietf.org_html_rfc4291-23section-2D2.5.5.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I14XA8I9Ruw5aBj5er_OVbvADz1sb9ZLFBGaZZlJJJ4&e=>*. >> IPv4-Mapped IPv6 Address* >> >> >> >> <p class="MsoNormal" style="margin:0in;margin-bottom:.0001pt;line-heigh >> >> -- -- Alex Alex Bogdanov | Strategic NetEng | bogdanov@ <bogdanov@google.com> | Cell: 650-314-8196
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… bruno.decraene
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- [RTG-DIR] RtgDir Early review: draft-ietf-spring-… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… stephane.litkowski
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Shraddha Hegde
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… stephane.litkowski
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Ahmed Bashandy
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Alexander Vainshtein
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-spr… Shraddha Hegde
- Re: [RTG-DIR] [spring] RtgDir Early review: draft… Przemyslaw Krol
- Re: [RTG-DIR] [mpls] [spring] RtgDir Early review… Alex Bogdanov
- Re: [RTG-DIR] [mpls] [spring] RtgDir Early review… Rob Shakir
- Re: [RTG-DIR] [mpls] RtgDir Early review: draft-i… Jeff Tantsura
- Re: [RTG-DIR] [spring] RtgDir Early review: draft… Loa Andersson
- Re: [RTG-DIR] [spring] RtgDir Early review: draft… Loa Andersson