Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11
Alvaro Retana <aretana.ietf@gmail.com> Thu, 21 March 2019 17:00 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1113145E; Thu, 21 Mar 2019 10:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU8h00aCfZgj; Thu, 21 Mar 2019 10:00:05 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 D87F8131456; Thu, 21 Mar 2019 10:00:04 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id 103so6054501otd.9; Thu, 21 Mar 2019 10:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=vo9f0u7azf4ypjeVcTKQzj1THbOeGVwfnsM5wUOA2K4=; b=QXlCwb4FxYHqUVt0F1yREybalIz3UyhmbgcB6ZSe8hKYlm9EQrOPvc6r8Bo8qzwxBo cwDJW4scNMj3F1Ysa1PrmdsokQSNk7qH6xrdyopb0mnrDV/juFGvoYKqDgLuIcUJySlh KokVdPhZJvksxjIA+CyOgup9D2H2/mMd3BLLYU33R8yu8nuz++SCTUtklbrmCge1TJnT XCyhTYUx0GhlNqIl63kj8cnGOR5QZ1/nKPHxJA2Oq87aM1FsYz9TFLdxHnGGmTbcd9nb TD+Erxi/NQ+GHmBZJx5BXaJRkWAqLKcIoqbLhQN11oj216UVMOAJ8+0ePk2OjrQcH/kX yrUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=vo9f0u7azf4ypjeVcTKQzj1THbOeGVwfnsM5wUOA2K4=; b=Zlru5QEjb7vwK8dK818p0U/BWX/sPd1IRa3AaRq78uHRUGGAA7w5dM5sQTdsnBVWKw ip931KvsTdwD0XBfZky8YjrYIAuwLBW54PSpX3jzQrK3z1gRZ3qEv8OIJsbWDd3XfkA8 qGInJK4fzupf+sDObNn+ZYCiuYiVuUbIJmkryeZJpnUzbonh+2ElJXm34vgQ1kc91DSd DPrXZWO8oSx1DLVSnGFXIV6hXcUVEyg9X5cVIWKj3AkTTxKYCXsUwsy6bLB2kwXnqGne PjwWPYQTl2Py8/7Cnqx7epCKvQPldnCh62COqmxAaBZwX37oh3+NJ1t4TtO3CDdKrBRa q0pw==
X-Gm-Message-State: APjAAAWXs6Nu0N5Zy0KrE6c4X8M/dIwPpRhwX7V8JTxxpUioxFc4P2iA x4UR6/N1df97S9kdeI3MVHG3l4zh9Hlf6L69o3KfCQ==
X-Google-Smtp-Source: APXvYqyt1ilUU6pbTl6gFgRGvJlFFpnYR1yZXmV68XiOaGBjtv4kd6NDX+rWLJ3Jooh585UeI+ay/fseAC4JQtid57c=
X-Received: by 2002:a05:6830:13cd:: with SMTP id e13mr3442123otq.139.1553187603882; Thu, 21 Mar 2019 10:00:03 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Mar 2019 10:00:02 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Thu, 21 Mar 2019 10:00:02 -0700
Message-ID: <CAMMESsxPMj1qnxyxv4R2prqTNbwLQ0+FjDB_-URmx-0=UnvFyQ@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" <draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000066492a05849dabc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BCbLexRHUFM_NoOo4no3L83knlU>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2019 17:00:10 -0000
On March 8, 2019 at 10:41:58 PM, Ketan Talaulikar (ketant) (ketant@cisco.com) wrote: Ketan: Hi! ... (1) Consistency in the specification of the new TLVs. Most of the descriptions point at other documents, but they don't do so in a consistent manner: some at the start of the section, others when pointing at the values, etc. Please be consistent! Given that §2.4/2.5 already have a summary, I personally find the information in the individual sections redundant. Instead of a statement at the start of a section, I prefer you to be specific about the values -- see §2.1.2 for an example. [KT] I have made some changes to address this and will wait for some clarification from you on this point. Please check my responses on such points further below. It looks like we have different opinions. :-) Proposal: for consistency, let’s use the approach from rfc7752, ok? In rfc7752 I see a couple of different things: (1) For TLVs that are formatted exactly as IGP TLVs: simple tables point at the origin TLV, and (if needed) a short explanation. For example, look for TLV 258 (§3.2.2). The SR Algorithm TLV is an example of this, where the format is exactly the same as the corresponding IGP TLVs. No need to even include a figure for the TLV... Note that others, like the SR Local Block TLV are in a similar situation: the format, with minor exceptions, come from equivalent IGP TLVs. In this case, pointing at the specific IGP TLV and mentioning the difference (no Flags field in OSPF, for example) should be ok. (2) For TLVs that have values that don’t map to a specific IGP TLV: the fields are defined in function of where information comes from. For example, see the Multi-Topology ID TLV (§3.2.1.5). I think that the Source Router Identifier (Source Router-ID) TLV is an example. Until we agree on the formatting I’m not considering the related comments (yours or mine) below, with a couple of exceptions. Maybe we can find some time next week to talk about this. ... ... 200 Some of the TLVs defined in this document contain fields (e.g. flags) 201 whose semantics need to be interpreted accordingly to the respective 202 underlying IS-IS, OSPFv2 or OSPFv3 protocol. The receiver of the 203 BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the 204 NLRI and refer to the underlying protocol specification in order to 205 parse such fields. The individual field descriptions in the sub- 206 sections below point to the relevant underlying protocol 207 specifications for such fields. [major] "The receiver of the BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the NLRI and refer to the underlying protocol specification in order to parse such fields." This text is a general statement ("for any of the NLRIs") that seems to want to Update rfc7752, where Protocol-ID is defined...but I don't think that is the intent, right? Note that rfc7752 doesn't explicitly mandate that the "receiver...refer to the underlying protocol specification" -- it just implies it when talking about the Opaque TLVs. [KT] Actually in this case, the protocol needs to be used by the consumer of the information to interpret certain fields in the BGP-LS TLVs. E.g. Adjacency SID in sec 2.2.1, the flags field is different in OSPF and ISIS and based on the flags the SID/index/label field needs to be decoded. IOW, this seems like a significant change as related to other BGP-LS specs. [KT] I will agree that it is a deviation from other BGP-LS specs including the base where we have tried to define IGP agnostic flags. I think the placement of this sentence gives the wrong impression that it wants to update rfc7752. It may be better placed if this was move (and may be repeated) for only those TLV fields where this kind of protocol specific decoding is necessary. I have updated the draft for this. e.g. for sec 2.2.1, I would propose to add the following text at the end of the TLV fields description: "The Flags and, as an extension, the SID/Index/Label fields of this TLV need to be interpreted accordingly to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The consumer of the BGP-LS interested in this TLV information MUST check the Protocol-ID of the BGP-LS Link NLRI and refer to the underlying protocol specification in order to parse these fields." Note also that §5 (Manageability Considerations) has the following text, which I think is in contradiction of the one above: [KT] I think this section should be using the term "consumer of the BGP-LS information" and not "receiver". Fixed this. Because what the consumer does is outside the scope of this document, I think that the best path forward is to simply delete the text above completely. Note that now (placed in the different sections) is, at best, redundant (because the sections specify the fields anyway... ... ... 290 Length: Variable. [major] Yes, it's variable, but it has to be at least 12. What should a router do if the length is < 12? After that, there are only specific valid [KT] I have updated for the minimum length for the TLVs. However, it is not very helpful to try and list all other valid values (in some cases, cannot even say "in multiple of X"). lengths: 12, 13, 19, 21, etc. What if the length is not one of those values? I couldn't find guidance in rfc7752. The closest statement is from §6.2.2 (Fault Management), where one of the "checks for determining if a message is malformed...Does any fixed-length TLV correspond to the TLV Length field in this document?" This TLV is not fixed-length, but the possibilities are finite. Note that rfc7752 says that if the length is not the expected one, then the whole BGP-LS attribute is discarded. For this specific case, it means that the controller wouldn't have complete knowledge of the network, even if the information derived from the IGP is correct... [KT] I would take this in the generic RFC7752 context and not specific for this draft. Yes. I agree with your comments and point of view. About the specific lengths above: yes, it’s hard to characterize the valid lengths. Given the limitations in rfc7752, what I’m trying to do is to be able to characterize these TLVs as having a fixed length because that is the only case covered in rfc7752. ;-) ... ... 339 2.1.4. SR Local Block TLV ... 380 Flags: 1 octet of flags. None are defined at this stage. [major] Only the corresponding ISIS sub-TLV has Flags defined -- and I realize that the text above is the same as in draft-ietf-isis-segment-routing-extensions. I think you really don't want this field to evolve independently. IOW, please use a description like the you used for the Flags in the SR-Capabilities TLV. [KT] Actually, I would prefer the BGP-LS flags and encodings to evolve independent of the IGPs (but mapping and encompassing their encodings) so that consumers don't need to be exposed to IGP specifics (where possible) for decoding/interpretation of values that can be modelled in an IGP independent manner. We could not do this for some of the initial TLVs/fields since there wasn't a consensus on this within authors/contributors. I hope we can going forward unless the WG feels differently. I think that the hard/confusing part about this approach would be that some bits in the flags may be important for the BGP-LS consumers…and others not. This means that if the Flags are not in sync, we could run into a case where no more BGP-LS flags exist for a new (and interesting) IGP flag. This specific TLV doesn’t bother me too much because there is a Reserved field in it…so that could be used to diverge, if needed. ... 393 2.1.5. SRMS Preference TLV ... 427 The use of the SRMS Preference TLV is defined in 428 [I-D.ietf-isis-segment-routing-extensions], 429 [I-D.ietf-ospf-segment-routing-extensions] and 430 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [major] This document only defines how to carry information in BGP-LS, not what to do with it. IOW, I think that the last paragraph is not needed, it is out of scope of this document... [KT] This is true for almost everything in BGP-LS since it is only a carrier of information. This info is meant for the consumer of the BGP-LS info on how this is used. E.g. it helps pick mapping of one SRMS server over the other - this way the consumer application would be able to get the right label to prefix mapping as advertised by that server. But by providing instructions/hints for the consumer we are going beyond the scope of the document. IOW, if we want the consumer operation, including semantic checks, etc. to be in scope…then let’s make it in scope for everything. In the specific case of this TLV, I think that knowing the source of the information provides the other background needed and the text above is still not needed. ... ... 749 2.3.4. Range TLV 751 The range TLV is used in order to advertise a range of prefix-to-SID 752 mappings as part of the Segment Routing Mapping Server functionality 753 [I-D.ietf-spring-segment-routing-ldp-interop], as defined in the 754 respective underlying IGP SR extensions 755 [I-D.ietf-ospf-segment-routing-extensions], 756 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and 757 [I-D.ietf-isis-segment-routing-extensions]. The Prefix-NLRI to which 758 the Range TLV is attached MUST be advertised as a non-routing prefix 759 where no IGP metric TLV (TLV 1095) is attached. [major] What do you mean in the final sentence? It sounds as if the IGP metric TLV and the Range TLV are mutually exclusive and should never be advertised together. Is that it? If so, what should the receiver do if they are? [KT] I have rephrased this since they are not mutually exclusive. The point about the IGP Metric TLV was that a consumer of a Prefix NLRI originated on account of a SRMS mapping should not mistake this prefix to be like a normal prefix reachability - it can detect this by the absence of the IGP Metric TLV which is included for all "real" prefix reachability advertisements. The updated text says that a “consumer...MUST NOT mis-interpret a Prefix NLRI, that been advertised with a Range TLV...as a normal routing prefix (i.e. prefix reachability) unless there is also an IGP metric TLV (TLV 1095) attached to it.” Here we’re giving instructions to the consumer…and they are not clear: what does “mis-interpret” leads to? Instead, maybe something like this: ...a Prefix NLRI, that been advertised with a Range TLV…is considered a normal routing prefix (i.e. prefix reachability) only when there is also an IGP metric TLV (TLV 1095) attached to it… This way we still convey the purpose, but avoid trying to specify what the consumer should do. ... 994 A consumer of the BGP-LS information is retrieving this information 995 from a BGP protocol component that is doing the signaling over a BGP- 996 LS session, via some APIs or a data model (refer Section 1 and 2 of 997 [RFC7752]). The handling of semantic or content errors by the 998 consumer would be dictated by the nature of its application usage and 999 hence is beyond the scope of this document. This document only 1000 introduces new Attribute TLVs and an error in them would result in 1001 only that specific attribute being discarded with an error log. [nit] s/is retrieving this/retrieves this [KT] ack - fixed [minor] "...retrieving this information...over a BGP-LS session, via some APIs or a data model (refer Section 1 and 2 of [RFC7752])." I think that even mentioning that an API or data model can be used instead of BGP-LS is a stretch -- that is not how I interpret the initial sections in rfc7752 (which are just background sections), and there are no formal API/data model definition. [KT] How else would Alto Server or a PCE component get access to the BGP-LS information? There would be some APIs or a model. It may not be formal but there needs to be one? rfc7752 specifies how the consumer uses a BGP-LS session…not anything else. The full sentence is this: "A consumer of the BGP-LS information retrieves this information from a BGP protocol component that is doing the signaling over a BGP-LS session, via some APIs or a data model (refer Section 1 and 2 of [RFC7752]).” A consumer of BGP-LS uses BGP-LS…. This is a minor point anyway. The important part is about semantic checking being out of scope. ... 1009 6. Security Considerations 1011 The new protocol extensions introduced in this document augment the 1012 existing IGP topology information that was distributed via [RFC7752] Hmmm… It looks like this was also truncated — I wonder why that is happening. I put the rest of the review below. Thanks! Alvaro. 1009 6. Security Considerations 1011 The new protocol extensions introduced in this document augment the 1012 existing IGP topology information that was distributed via [RFC7752]. 1013 The Security Considerations section of [RFC7752] also applies to 1014 these extensions. The procedures and new TLVs defined in this 1015 document, by themselves, do not affect the BGP-LS security model 1016 discussed in [RFC7752]. [nit] s/that was distributed/that is distributed 1018 BGP-LS SR extensions enable traffic engineering use-cases within the 1019 Segment Routing domain. SR operates within a trusted domain (refer 1020 Security Considerations section in [RFC8402] for more detail) and its 1021 security considerations also apply to BGP-LS sessions when carrying 1022 SR information.The SR traffic engineering policies using the SIDs 1023 advertised via BGP-LS are expected to be used entirely within this 1024 trusted SR domain (e.g. between multiple AS/domains within a single 1025 provider network). Therefore, precaution is necessary to ensure that 1026 the SR information collected via BGP-LS is limited to specific 1027 controllers or applications in a secure manner within this SR domain. [nit] s/trusted domain (refer Security Considerations section in [RFC8402] for more detail)/trusted domain [RFC8402] [nit] s/SR information.The SR traffic/SR information. The SR traffic [major] "SR operates within a trusted domain...[RFC8402]...and its security considerations also apply to BGP-LS sessions when carrying SR information." The Security Considerations in rfc8404 really only talk about the data plane -- I don't see how they apply to the BGP-LS sessions. [major] "...precaution is necessary to ensure that the SR information collected via BGP-LS is limited to specific controllers or applications..." This sounds as if you're referring to information that (once collected) can be shared between controllers -- I think that case is out of scope. If you are trying to talk about the BGP sessions, then I think the language needs a little more work. BTW, the paragraph below also talks about BGP sessions; suggestion: keep the common topics together. [major] The end of the last sentence says "...in a secure manner within this SR domain". Assuming that we're talking about BGP sessions, what does that mean? Does it mean anything beyond what BGP is normally specified to do? If not, then I would recommend taking that piece of text out to not invite more questions than needed. [minor] You talk about "controllers or applications", but in the rest of the document you have mostly used "consumer" (which is a good thing because it shows consistency with rfc8402). Suggestion: use "consumers" here as well. 1029 The isolation of BGP-LS peering sessions is also required to ensure 1030 that BGP-LS topology information (including the newly added SR 1031 information) is not advertised to an external BGP peering session 1032 outside an administrative domain. [major] What does "isolation of BGP-LS peering sessions" mean? Why is it not Normatively REQUIRED? [major] From prior experience (see draft-ietf-idr-te-pm-bgp), the SecDir/Sec ADs asked for text related to why it is ok to transport the new information in BGP. This is the text that resulted from that discussion: The TLVs introduced in this document are used to propagate IGP defined information ([I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471].) These TLVs represent the state and resource availability of the IGP link. The IGP instances originating these TLVs are assumed to support all the required security and authentication mechanisms (as described in [I-D.ietf-lsr-isis-rfc7810bis] and [RFC7471]) in order to prevent any security issue when propagating the TLVs into BGP-LS. The advertisement of the link attribute information defined in this document presents no additional risk beyond that associated with the existing set of link attribute information already supported in [RFC7752]. Note that this text is complementary to what is already stated in the first paragraph -- but goes into a more explicit explanation and brings in the security considerations from the documents where the IGP extensions are defined. Consider adding something similar here. ... 1126 9.2. Informative References ... 1159 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1160 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1161 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1162 July 2018, <https://www.rfc-editor.org/info/rfc8402>. [major] I think this should be a Normative reference.
- [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Alvaro Retana