Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-16

Alia Atlas <akatlas@gmail.com> Wed, 31 May 2017 02:35 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BF2126D46; Tue, 30 May 2017 19:35:27 -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 G0KLSXMc7xR6; Tue, 30 May 2017 19:35:23 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 E14D5126CF6; Tue, 30 May 2017 19:35:22 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id j27so1260801wre.3; Tue, 30 May 2017 19:35:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mwinlic2KR4eK5F6xUfHQPWE3m0Jeqj7Ugyzw6yq1nA=; b=LSoAc7Q5YkbXIu1GpyODgWdJSvP896/WXX+86Nk2YV5IusJF9rn16ohCIgEiYEtRfT vwmAJ3DpXIw0aIBtMtGTkUXftcLZxqx8vlqiA1AEaL/3w1jGeC43lVdALy8wVddeRDLd hTv1ZoQTbC7qTykItlxBGwL9Lhu338BhbAnfMJv/vBJG6WCujxAoogOQU1lIfDMFRcRV pwQOr3skFWtxQ8jTr6G3DfJd/F/8ORCGARa8aFb/0wIKKMa7xFhk9mTiD2Od5hnnHLBx np67K9R5TTSM76OOZL26QpZgKFTGmvXsX8m+5b1ts75p6EFl8BowjR1c01d2CeDgnne6 BszQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mwinlic2KR4eK5F6xUfHQPWE3m0Jeqj7Ugyzw6yq1nA=; b=aNxbACs9L+MDR2YJuEPu+dsftmRPGbfsZPd+TL58GJd1PlL4VXF0SeY9prG4eKL3Oc 3fs3suNfA6LNXAoscF5n+dj23Bq378zIXnITPYEJd90TLOaBMPy9WxpJsFBH1jE/Lpd2 PB6tj36QzIcEYUD/Sa1azcAJ8gdohy90ELeXWI/fkBl+MEOXoCTY4dWqgMtPGhb1WC5Y GUOQKk3I1djDU1cK730fTvuOoRYRC5IWEjszTk/O1LSoGQaK7aLdH7hJ2oy6ZKlp+Imi NKdCbHLWjyMIy6IQ6TSvZq0s1/DCKnNVNepSOTN8yrVR5+76t6EbfZ0j1l0wT025fPrw V+WA==
X-Gm-Message-State: AODbwcAYfA6q5QTZ9f9OqJxC2BizaxmBWVbEgIXOev5hrmAR2tHyO5EB oItng0rYt9P1YyfHg5rOzBnbkagXFFJA
X-Received: by 10.223.133.182 with SMTP id 51mr16714799wrt.86.1496198121243; Tue, 30 May 2017 19:35:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.86 with HTTP; Tue, 30 May 2017 19:35:20 -0700 (PDT)
In-Reply-To: <CAG4d1rc63W09vsg5psyUFYdF-1ygX3oD+J+4Rbjd0CoXTi08vA@mail.gmail.com>
References: <CAG4d1rc63W09vsg5psyUFYdF-1ygX3oD+J+4Rbjd0CoXTi08vA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 30 May 2017 22:35:20 -0400
Message-ID: <CAG4d1rfCJzbUM8rhehd1t3ibm9jMGDz=AR=QWkCWmM5Jh38vVA@mail.gmail.com>
To: OSPF List <ospf@ietf.org>, draft-ietf-ospf-segment-routing-extensions@ietf.org, Alvaro Retana <aretana@cisco.com>, "BRUNGARD, DEBORAH A (ATTSI)" <db3546@att.com>
Cc: "spring-chairs@tools.ietf.org" <spring-chairs@tools.ietf.org>
Content-Type: multipart/alternative; boundary="001a11497f9887c8d60550c8c5ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/tw3kPgWTGIpMjDKFIwNDo59kxoQ>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-16
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2017 02:35:27 -0000

I forgot to point out that the Security Considerations sections is not
close to sufficient.
At a minimum, it needs to refer to the existing security work for OSPF,
indicate what new
information is being advertised, and discuss if there are any privacy or
security concerns
around them.  I don't personally see any - except for, perhaps, the
increased ability to fingerprint
the type and version of routers with these advertisements.

Regards,
Alia

On Tue, May 30, 2017 at 10:05 PM, Alia Atlas <akatlas@gmail.com> wrote:

> As is customary, I have done my AD review of draft-ietf-ospf-segment-routing-extensions-16
> once publication has been requested.  First, I would like to thank the
> editors & many authors, Peter, Stefano, Clarence, Hannes, Rob, Wim & Jeff,
> for the work that they have put in so far and the remaining work that is
> greatly needed.
>
> While there are a great many issues to be handled, they fall primarily
> into three categories.  The first is simply not going through and
> tightening up the details; for example, stating that the length of a TLV is
> variable provides no meaning.  The second is that the technical documents
> from SPRING that this draft depends on do not adequately describe the use
> of the advertised information (SID/Label Binding TLV) or some of the
> concepts (e.g. SR Mapping Server).  The third is a more common set of
> handling error cases and adding clarity to the intended behavior.  I do not
> see issues with the encodings but I do see fragility with the unstated
> assumptions and behaviors.  The draft describes encodings, but very little
> of the handling, behaviors, or meaning - and the references do not provide
> adequate detail.
>
> I have spent all day (and evening) doing this review and I am quite
> disappointed and concerned about the document.  I would strongly recommend
> having sharing the next WGLC with the SPRING working group; perhaps more
> eyes will help with the discrepancies.
>
> I have not yet decided what to do about the "early" IANA allocation -
> which has now existed for this draft for 3 years.  I do know that there are
> implementations,
> but I am currently seeing the failure of this work to successfully
> complete as an example of an issue with providing early allocations.
>
> MAJOR ISSUES:
>
> 1) This draft has 7 authors.  The limit for authors & editors is 5, as is
> clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well over a
> decade, unless there are extraordinary circumstances.  Is there a reason to
> not simply list the active editor and move the others to contributors?  One
> of the authors is already listed there.  I regret that failure to deal
> earlier with this long-standing IETF policy will be delaying progressing
> the draft.
>
> 2) This expired individual draft(draft-minto-rsvp-lsp-egress-fast-protection-03)
> is listed as Informative - but IS ACTUALLY NORMATIVE since it DEFINES the
> "M-bit - When the bit is set, the binding represents a mirroring context
> as defined in [I-D.minto-rsvp-lsp-egress-fast-protection]."
>  Unfortunately, when I look there for the definition of a mirroring
> context, it doesn't exists.
>
> 3) The following Informative references expired several years ago and -
> being individual drafts - do not appear to convey the SPRING or TEAS WG
> consensus.
>    a)  draft-filsfils-spring-segment-routing-ldp-interop-03 was replaced
> with draft-ietf-spring-segment-routing-ldp-interop-07 and there are
> considerable differences.
>    b) It is unclear what happened to draft-filsfils-spring-segment-routing-use-cases-01,
> but I do not see any successor - or reason for this individual draft to
> explain the OSPFv2 extensions more than work from the SPRING WG.
>
> 4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the
> SR-Algorithm TLV?  What is the expected behavior and assumptions by the
> receiver?
>
> 5) Sec 3.4:  What happens if an SRMS Preference TLV is advertised without
> an SR-Algorithm TLV in the same scope?  I see that it says "For the purpose
> of the SRMS Preference Sub-TLV advertisement, AS scope flooding is
> required." but also provides for area scope flooding.  Some words
> clarifying the expected behavior would be useful.
>
> 6) Sec 5: "In such case, MPLS EXP bits of the Prefix-SID are not preserved
> for
> the final destination (the Prefix-SID being removed)."   I am quite
> startled to see an assumption that MPLS Pipe mode is being forced as part
> of specifying PHP mode!  This will also break any ECN or 3-color marking
> that has affected the MPLS EXP bits.  I would like to see and understand a
> clear justification for why short-pipe mode is being required instead of
> Uniform (or up to implementation/configuration.).   Basically, this
> sentence means that transport considerations are a necessary section -
> which is completely inappropriate in an IGP draft.
>
> 7) Sec 6: This section defines the SID/Label Binding sub-TLV - which
> appears to be a way to advertise an explicit path - and has a SID/Label by
> which the path can be entered.   How and what state is set up by the
> sending router to create the indicated segment is completely unclear.   I
> have hunted through draft-ietf-spring-segment-routing, draft-ietf-spring-segment-routing-mpls,
> and draft-ietf-spring-segment-routing-ldp-interop, RFC7855,
> and draft-ietf-isis-segment-routing-extensions.   As far as I can tell,
> NONE of them clearly describe the details of where and why this advertising
> is needed.  Obviously, this mechanism does allow the potential shortening
> of the MPLS label stack at the cost of advertising multi-hop explicit path
> segments across the entire area or AS.  There MUST be a normative
> description of what the sending router will do when a packet is received
> with the specified label.
>
> 8) Sec 4: "The Segment Routing Mapping Server, which is described in
> [I-D.filsfils-spring-segment-routing-ldp-interop]"  Where precisely is an
> SRMS and its behavior/role actually defined?  draft-ietf-spring-segment-routing-ldp-interop-07
> claims:"SR to LDP interworking requires a SRMS as defined in
> [I-D.ietf-isis-segment-routing-extensions]." but that wouldn't be
> appropriate, of course, and it isn't there either!
>  draft-ietf-spring-conflict-resolution-04 talks about SRMS, but doesn't
> define it.   draft-ietf-spring-segment-routing-11 mentions in Sec 3.5.1
> that "A Remote-Binding SID S advertised by the mapping server M" and refers
> to the ldp-interop draft for further details - but obviously not about an
> SRMS.
>
> Minor Issues:
>
> 1) In Sec 3.1, it says: "The SR-Algorithm TLV is optional. It MUST only be
> advertised once in the Router Information Opaque LSA.  If the SID/Label
> Range TLV, as defined in Section 3.2, is advertised, then the SR-Algorithm
> TLV MUST
> also be advertised."  Please provide a pointer in the text to the behavior
> for a receiving router if one or both of these are violated?   For the
> requirement to advertise the SR-Algorithm TLV, please clarify that this is
> in the same RI LSA as the SID/Label Range TLV was advertised & with the
> same scope.  What does it mean, in terms of the receiving router, to
> determine that the sending router supports SR or not - given the
> possibility of receiving other SR-related TLVS in an RI LSA without getting
> an SR-Algorithm TLV?
>
> 2) Sec 3.1: The SR-Algorithm TLV simply defines "Length: Variable".  Given
> that advertising Algorithm 0 is required, I'm fairly sure that the Length
> has to be a minimum of 1 - and, to prevent overrun & weird issues, let's
> have a reasonable maximum (for instance, 24) too.  It wouldn't hurt to
> remind readers that the length is just that of the value field - though
> experienced OSPF implementers will know that.
>
> 3) Sec 3.1 & Sec 3.2 & Sec 3.3: "For the purpose of SR-Algorithm TLV
> advertisement, area scope flooding is required." and "For the purpose of
> SID/Label Range TLV advertisement, area scope flooding is required."  and
> "For the purpose of SR Local Block Sub-TLV TLV advertisement, area scope
> flooding is required." Please capitalize REQUIRED as per RFC 2119.
> Otherwise, please explain behavior when area scope isn't used.
>
> 4) Sec 3.2:  The SID/Label Range TLV doesn't indicate that include a
> SID/Label sub-TLV is required - but I don't understand how it could be
> interpreted otherwise; nor does it indicate what to do if there are
> multiple SID/Label sub-TLVs included in a single SID/Label Range TLV. Again
> "Length" is just defined as variable.  In this case, it clearly can't be
> less than 11 (probably 12, assuming padding to the 32-bit boundary).   It
> would be useful to have an upper-bound on length, but at least here I can
> see the argument that meaningful flexibility is provided for.
>
> 5) SID index is used without introduction in Sec 3.2.  It isn't defined in
> the terminology of draft-ietf-spring-segment-routing-11 and the other
> uses of it in this document aren't enough to clearly define it.  Please add
> at least a description of its meaning before use - in a terminology
> section, if necessary.
>
> 6) Sec 3.2: "The originating router advertises the following ranges:
>          Range 1: [100, 199]
>          Range 2: [1000, 1099]
>          Range 3: [500, 599]"
> Please turn this into the information actually advertised - i.e.
>    Range 1: Range Size: 100   SID/Label sub-TLV: 100  => meaning [100, 199]
> etc.
>
> 7) 3.2. SID/Label Range TLV:  Please specify that the sender MUST NOT
> advertise overlapping ranges & how to handle the case when it does.  This
> is required by draft-ietf-spring-conflict-resolution.
>
> 8) Sec 3.3  SR Local Block (SRLB) Sub-TLV: The document doesn't specify
> that the SR Local Block TLV MUST include a SID/Label sub-TLV nor indicate
> what to do if multiple are included.  The Length, again, isn't specified at
> all and clearly has at least a minimum.   I don't see a reference to an SR
> Local Block or the need to advertise it in draft-ietf-spring-segment-routing-11;
> perhaps I missed where the requirement and usage are defined?
>
> 9) Sec 3.3: "Each time a SID from the SRLB is allocated, it SHOULD also be
>    reported to all components..."  Presumably, this is subjected to the
> normal OSPF dampening - it'd be nice to note that somewhere - since rapid
> sequential allocation may not provide the reporting speed anticipated.
>
> 10) Sec 4: "AF: Address family for the prefix. Currently, the only
> supported
>       value is 0 for IPv4 unicast.  The inclusion of address family in
>       this TLV allows for future extension."  Could you please clarify if
> this is to reuse the same TLV for OSPFv3 so IPv6 can be supported, are you
> thinking of extending OSPFv2 for IPv6 prefixes for some cases or something
> else? I think the current phrasing is likely to raise questions.
> Similarly, please define "Prefix length: Length of the prefix" clearly.  I
> really don't understand what the benefit of having a TLV that pretends to
> support multiple AFs but can't is versus the clarity of specifying the
> prefix lengths.
>
> 11) Sec 4:  Again "Length: Variable" - It should have a minimum and
> preferable describe a function for how it is computed.  A maximum is
> probably unlikely  with sub-TLVs.
>
> 12) Sec 4: OSPF Extended Prefix Range TLV:  Does this TLV has any meaning
> or action associated with it without including sub-TLVs?  Are there
> mandatory sub-TLVs?  What is a receiving router to do with it?
>
> 13) Sec 5: "If multiple Prefix-SIDs are advertised for the same prefix, the
>   receiving router MUST use the first encoded SID and MAY use
>   subsequent SIDs."  What does this even mean?  A receiving router when
> making the decision to use a subsequent SID is making a decision to not use
> the first encoded SID; it's not like the router is going to stick both
> SID/Labels onto the stack.   Please describe this in meaningful normative
> terms.
>
> 14) Sec 5:" When calculating the outgoing label for the prefix, the router
> MUST
>    take into account the E and P flags advertised by the next-hop router
>    if that router advertised the SID for the prefix.  This MUST be done
>    regardless of whether the next-hop router contributes to the best
>    path to the prefix."  First, I assume this is "NP flag" because there
> is no P flag.
>    Second - please clarify to "take into account, as described below, the
> E and NP flags...".  Third, the M flag must also be taken into account -
> given the text later in the section.
>
> 15) Sec 5: "When a Prefix-SID is advertised in an Extended Prefix Range
> TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a
>    starting SID value."   This appears to contradict "SID/Index/Label:
> According to the V and L flags, it contains either:
>
>          A 32-bit index defining the offset in the SID/Label space
>          advertised by this router.
>
>          A 24-bit label where the 20 rightmost bits are used for
>          encoding the label value."
>   I assume that what is meant by the first quote is "...is interpreted, if
> the V flag is clear, as a starting SID value, and if the V flag is set, as
> a starting Label value."  Otherwise, it looks like the Prefix-SID sub-TLV
> couldn't be included in the Extended Prefix Range TLV if a label value
> would be used.
>
> It would be helpful for Example 2 to show the label case.
>
> 16) Sec 6.1: "aggregate IGP or TE path cost."  Given that this is an OSPF
> draft, it'd be helpful to indicate whether there are challenges with
> non-comparable OSPF metrics (I'm thinking about AS-external type 2 costs)
> or if the path will never include such costs.
>
> 17) Sec 6.2: "a domain and hence need to be disambiguated using a
> domain-unique Router-ID."  Given that the Prefix-SIDs and sub-TLVs can be
> distributed between areas and even redistributed between protocols, please
> clearly define what is meant by a "domain" or point to the appropriate
> definition.
>
> 18) Sec 4, 5, 6:  Is it possible to have an OSPF Extended Prefix Range TLV
> that includes both a Prefix SID Sub-TLV and a SID/Label Binding Sub-TLV?
> What does that mean?
>
> What does it mean if there are multiple prefixes described in the OSPF
> Extended Prefix Range TLV that includes a SID/Label Binding Sub-TLV?  Does
> the SID/Label sub-sub-TLV indicate a single SID Index or Label that is used
> for the single path to all those prefixes?  Is it the start of a list of
> SID Indices or Labels?
> I see that the SID/Label Binding sub-TLV can be in both the OSPF Extended
> Prefx Range TLV as well as the OSPF Extended Prefix TLV - but there is no
> text on differences in interpretation.
>
> 19) Sec 7.1 & 7.2: Another  couple "Length: Variable."  Please actually
> specify the value. I think that, given the padding to 32-bit alignment,
> there is a single correct value.
>
> 20) Sec 7.1 and 7.2: Given that the Flag bits have exactly the same
> meaning - it'd be clearer to have them defined once.
>
> 21) Sec 8.1: "An SR Mapping Server MUST use the OSPF Extended Prefix Range
> TLV when advertising SIDs for prefixes.  Prefixes of different route-types
> can be combined in a single OSPF Extended Prefix Range TLV advertised by an
> SR Mapping Server."    So - I can't find a normative definition of an SRMS
> to determine why it is always necessary to use an OSPF Extended Prefix
> Range TLV instead of an OSPF Extended Prefix TLV.   I don't see how
> advertising prefixes from different route-types can work unless the
> prefixes are adjacent, which seems likely to be uncommon.  Perhaps what is
> meant is "Because the OSPF Extended Prefix Range TLV doesn't include a
> Route-Type field, as in the OSPF Extended Prefix TLV, it is possible to
> include adjacent prefixes from different Route-Types in the OSPF Extended
> Prefix Range TLV."
>
> 22) Sec 8.1: "If multiple routers advertise a Prefix-SID for the same
> prefix, then
> the Prefix-SID MUST be the same.  This is required in order to allow
> traffic load-balancing when multiple equal cost paths to the destination
> exist in the OSPFv2 routing domain."  How is this enforced?  What are the
> consequences of it not being conformed to?  This is NOT a protocol
> implementation requirement.  This should really be called out in a
> Manageability Considerations with warnings.
>
> 23) Sec 8.2:"If no Prefix-SID was advertised for the prefix in the source
> area
>       by the router that contributes to the best path to the prefix, the
>       originating ABR will use the Prefix-SID advertised by any other
>       router when propagating the Prefix-SID for the prefix to other
>       areas."  I believe that this depends on the assumption that if a
> Prefix-SID is advertised by any router, the Prefix-SID will be the same.
> Please be explicit in this assumption, since the requirement on the network
> operator should be clear as well as the consequences of not conforming.
>
> 24) Sec 10:  The Implementation Status section should indicate that it is
> to be removed before publication as an RFC.   Also, the complete
> implementation part seems a bit dated - given the draft's technical changes
> in the last 2 years.
>
>
> NITS:
>
> 1) Sec 2.1: s/"SID/Label TLV"/"SID/Label sub-TLV"
>
> 2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Label TLV as
> defined
>    in Section 2.1.  The SID/Label advertised in the SID/Label TLV
>    represents the first SID/Label in the advertised range."
>    replace SID/Label TLV with SID/Label sub-TLV.
>
> 3) Sec 3.3 & Sec 3.4: " The SR Local Block (SRLB) Sub-TLV is a top-level
> TLV of the Router Information Opaque LSA (defined in [RFC7770])."   Please
> correct the descriptions (many) to SR Local Block (SRLB) Sub-TLV to SR
> Local Block SRLB TLV.   The same issue exists for "SRMS Preference Sub-TLV".
>
> Regards,
> Alia
>
>
>