Re: [mpls] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13

Ahmed Bashandy <abashandy.ietf@gmail.com> Mon, 11 June 2018 21:59 UTC

Return-Path: <abashandy.ietf@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 1FE71130EB4; Mon, 11 Jun 2018 14:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q48eqO12WMwr; Mon, 11 Jun 2018 14:59:30 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 B05DF127598; Mon, 11 Jun 2018 14:59:29 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id r125-v6so19334227wmg.2; Mon, 11 Jun 2018 14:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=rtfXn5IAcX1tnwKgbqBrLFfLUTc3sMcfVFN/gr38diA=; b=LT5guMsphyh8we8WabA9GCaL3LLrubPApcxwau1T+MdCkUDa3w0/+eBP2bCuhqIXmt tYgUTb+cPRMcysBytcKt/Cx4l/69svbrXEKnDhisfU3l88naqVfWRdIbzTu+4yPLtNAC JwiVPaCx/76R6PkV33Mb/g11ybKEkmX7pQOPkdjJNWL5HeJ11bzUA5x0yccG5GugHlKy QLPENh/lIaBWPsft+1Xv0vTJv7/Ws8+6PJINP2KqQTJinjKxn7XITtlcbpRGV4WAED8Z 4QuVWmH1viqVnDjl8ONuGiySWF2nO73LdGzyzzoLC16JBz2w9brbtvf7ViYgs0jTS9rS zvRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=rtfXn5IAcX1tnwKgbqBrLFfLUTc3sMcfVFN/gr38diA=; b=Urc/60XYax7v/CCnH1trnfbPjU894CEygRMfQZRoGCuXRRbw6gOmsDwdWGKpCFMyNv W7S61bP1UQp3iDQp2fex38a6gA+kGadgM/EjLdrB2n/XJPTo/nBEHhNI0opLJNsYG3d+ 8hV7ZmXhHk0/VnJcxNhDU0/S2XlysMZl0jg/H6ocr3sPZo6b7df0nHnpJ0HwX/uJyVQx qwHzAordi0QsZ9XNwujezt6omPNVxZEPFmwQ7mP1O9M1wr5mJTCenZ6oJyrNTXj5cSqA BvQm8JxS+6YVMKBg5+W+nHETKst1buXT0Kz6s8/YfW4px12nVM3iPxOS4KE7JMej/+/M wLcA==
X-Gm-Message-State: APt69E0ixn+/1HrqyjoAFf7m0XYwfxHu/eXID023pEi13v0gbhhlGMUY hOsjtk2ifjqevQPMbv9x77Q=
X-Google-Smtp-Source: ADUXVKLD3OpMNB4pzhWj8f0r9n0p66WK8vZK3E85JaQqfeVWCV2fG3KLyk+QjyqVP5W1LGRlziMGWA==
X-Received: by 2002:a1c:d483:: with SMTP id l125-v6mr377861wmg.98.1528754368117; Mon, 11 Jun 2018 14:59:28 -0700 (PDT)
Received: from [192.168.1.33] ([41.236.13.216]) by smtp.gmail.com with ESMTPSA id s2-v6sm43991289wrn.75.2018.06.11.14.59.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 14:59:27 -0700 (PDT)
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "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>
Cc: "spring@ietf.com" <spring@ietf.com>, "rtg-dir@ietf.org" <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" <shraddha@juniper.net>
References: <DB5PR0301MB19093D3B7D8159B9A341F5F79D790@DB5PR0301MB1909.eurprd03.prod.outlook.com>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <9d5960ea-d79f-1945-a8f0-9d8fa3f5afd2@gmail.com>
Date: Mon, 11 Jun 2018 14:59:25 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <DB5PR0301MB19093D3B7D8159B9A341F5F79D790@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------A2E0585809D42F7B06A885A2"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/x-MwiVCHhOX515_WigLQmqKGkP0>
Subject: Re: [mpls] RtgDir Early review: draft-ietf-spring-segment-routing-mpls-13
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 11 Jun 2018 21:59:37 -0000

I just posted version 14 to address Adrian's comments

I will address your comments in the next version in few days

thanks

Ahmed



On 6/10/18 12:43 AM, Alexander Vainshtein wrote:
>
> Explicitly adding Shraddha  who is the shepherd of this draft.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> 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>rg>; 
> '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>om>; rtg-dir@ietf.org; 
> mpls@ietf.org; '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/
>
> 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
>
> *Document*: draft-ietf-spring-segment-routing-mpls-13
>
> *Reviewer*: Alexander (“Sasha”) Vainshtein 
> (alexander.vainshtein@ecitele.com 
> <mailto: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://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
> 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://tools.ietf.org/html/rfc8287> 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
>
> *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.
>
> 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).
>
> 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.
>
> 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.
>
> 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
>
> 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.
>
> 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?
>
> 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.
>
> 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?
>
> 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.
>
> f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I am not sure all 
> SID types defined in the Segment Routing Architecture draft can be 
> unambiguously mapped to one of these types. Problematic examples 
> include at least the following:
>
> i.Parallel Adjacency SID
>
> ii.Mirror SID
>
> Explicit mapping of SID types to SR-MPLS FEC types would be most 
> useful IMO. If some SID types cannot be mapped to SR-MPLS FECs, this 
> must be explicitly stated in the draft.
>
> 6.*Node SIDs in SR-MPLS*:
>
> a.Node SIDs are explicitly defined and discussed in the Segment 
> Routing Architecture draft but are not mentioned even once in this draft
>
> b.AFAIK, the common implementation practice today includes assignment 
> of at least one Node SID to every node in the SR-MPLS domain
>
> c.Is there a requirement to assign at least one Node SID per {routing 
> instance, topology, algorithm} in SR-MPLS? If not, can the authors 
> explain expected behavior of such a node? (See also my comment about 
> routing instances below).
>
> 7.*SRGB Size in SR-MPLS*:
>
> a.The draft correctly treats the situation when an index assigned to 
> some global SID cannot be mapped to a label using the procedure in 
> Section 2.4 as a conflict.
>
> b.At the same time the draft does not define any minimum size of SRGB 
> (be it defined as a single contiguous block or as a sequence of such 
> blocks) that MUST be implemented by all SR-capable nodes
>
> c.I suspect that lack of such a definition could be detrimental to 
> interoperability of SR-MPLS solutions. AFAIK, the IETF has been 
> following, for quite some time, a policy that some reasonable 
> MUST-to-implement defaults should be assigned for all configurable 
> parameters exactly in order to prevent this.
>
> 8.*Algorithms and Prefix SIDs*:
>
> a.The draft mentions Algorithms (as part of SR-MPLS Prefix FEC) in, 
> but it does not explicitly link them with the Prefix-SID algorithms 
> defined in section 3.1.1 of the Segment Routing Architecture draft
>
> b.From my POV, the draft should explicitly state that the default 
> Prefix-SID algorithm MUST be implemented in all SR-MPLS-compliant routers.
>
> c.The Segment Routing Architecture draft states (in section 3.1.3) 
> that “Support of multiple algorithms applies to SRv6”. But neither 
> draft states whether multiple algorithms apply to SR-MPLS. Can you 
> please clarify this point?
>
> 9.*Routing instances and the context for Prefix-SIDs*:
>
> a.The Segment Routing Architecture draft states in Section 3.1 that 
> the “context for an IGP-Prefix segment includes the prefix, topology, 
> and algorithm”
>
> b.This draft seems to define (in section 2.5) the context for the 
> Prefix SID as “Prefix, Routing Instance, Topology, Algorithm” where ”a 
> routing instance is identified by a single incoming label downloader 
> to FIB” (but the notion of the label downloader to FIB is not defined).
>
> c.These two definitions look different to me.
>
> d.At the very least I would expect alignment between the definitions 
> of context for the Prefix-SID between the two drafts. Preferably, the 
> definition given in the Segment Routing Architecture draft should be 
> used in both drafts.
>
> 10.*Example of PUSH operation in Section 2.10.1*:
>
> a.The first para of this section begins with the sentence “Suppose an 
> MCC on a router "R0" determines that PUSH or CONTINUE operation is to 
> be applied to an incoming packet whose active SID is the global SID 
> "Si"”. In the context of SR-MPLS this means (to me) that the incoming 
> packet is a labeled packet and its top label matches the global SID “Si”.
>
> b.However, the example for PUSH operation in the next para of this 
> section is the case of an (unlabeled) IP packet with the destination 
> address covered by the IP prefix for which “Si” has been assigned.
>
> c.From my POV:
>
> i.Mapping unlabeled packets to SIDs is indeed out of scope of the 
> draft. Therefore an example of a PUSH operation that is applied to a 
> labeled packet (with the active SID inferred from the top label in the 
> stack) is preferable.
>
> ii.Valid examples of  PUSH operation applied to a labeled incoming 
> packet can be found in Sections 4.2 or 4.3 of the TI-LFA 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04> 
> draft
>
> *Nits*:
>
> 1.I concur with Adrian regarding numerous nits he has reported in his 
> WG LC Comment 
> <https://mailarchive.ietf.org/arch/msg/spring/FRhO2lgR8r4VlKP2ZN2dZwHU5BY>. 
> I would like to thank Adrian for an excellent review that have saved 
> me lots of hard work.
>
> 2.In addition, I’d like to report the following nits:
>
> a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the TI-LFA 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04> 
> draft)
>
> b.TI-LFA draft is referenced in the text of Section 2.11.1, but there 
> is no matching reference in the “References” section (probably, 
> Informational)
>
> c.“zero Algorithm” in Section 2.5 (immediately above Section 2.5.1) 
> must be replaced with “default algorithm”. Similarly, “non-zero 
> Algorithm” should be replaced with “non-default algorithm”
>
> 3.I think that RFC 3443 and RFC 5332 should be listed as Normative 
> references in this draft while RFC 5331 and RFC 8277 should be listed 
> as Informative references. This would improve the readability of the 
> draft without any impact on its advancement.
>
> Hopefully, these comments will be useful.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email: Alexander.Vainshtein@ecitele.com 
> <mailto:Alexander.Vainshtein@ecitele.com>
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________