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