Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT)
Ahmed Bashandy <abashandy.ietf@gmail.com> Sun, 02 September 2018 21:29 UTC
Return-Path: <abashandy.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995D3130DF1; Sun, 2 Sep 2018 14:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 aTJ6L6vzAiBz; Sun, 2 Sep 2018 14:29:00 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 72295130E11; Sun, 2 Sep 2018 14:29:00 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id 2-v6so7150964pgo.4; Sun, 02 Sep 2018 14:29:00 -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-transfer-encoding:content-language; bh=RltJJu9iW4bH0ZoYktiSC+evINgHsT8Vxx09myqRIbU=; b=cjxIFU0/mgCUkSsbtM+2C91w97Y3QulQ0DZFED1uAc5ELxpGzaq11oTiAzi4AGzT7F y3fMOW82lrosL6iFofT1Jv+mOPYLJMKh/noprig9UqwkQXfANnA6ySycYVwlcOMM7yMW ooUGupXw6Cz+BPdAYrZjbTx/jirGQ/HSVzWl0kpwDDRyLsvNsxK2kDu/Whx35MEIu2U+ D1/qzohNcdWi2n73VbVPGIc5UYu6mOhYb1llI8gaywb0nVBmvSwR+VJC+WKUlSlNAXnG tTnvLfvVg8S8FU++rnsar9arORVqYcVQTUUBWe/fRLsHeeIM4SNe2abu96QggrEXSPZa Sg5A==
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-transfer-encoding :content-language; bh=RltJJu9iW4bH0ZoYktiSC+evINgHsT8Vxx09myqRIbU=; b=nd/roNr2TiJ2x9hs2RMlQmwsy3aoPT0Fz38KB38woReotnz7lnZymjt62uS7HltA3e K5tArsGnscoBp2pu0HnPD3lOpGHXLfbiax5LGYdIt4Q4TlAntNVPMi2DlbKyDNlb9VMm brXMX67f0IpPFhP6aqCjCsQ041RTH4y0qHHN4TBetPhs//aGAuucGvgLr3EfD4GaZSM0 RwPYKZ6I+N7xHuY19/J5RBMhdAhZVeeyf2Df4CbPj0YPfAknr6YPeFiAqnzCSTZrGaMG YnvbccDpnrxBNImaGqXM807gHH6Jqoa+XX7Fdt5utv2AWLti9A7hnj1qo/VRWBkXeAcf npkw==
X-Gm-Message-State: APzg51Aas/CvfYwoKkEddofR5cp4ww7R/WKOrgB2uDJi9FC6JKRdb4UJ oAH2IT3PLNECJHAUxMNwt+Y=
X-Google-Smtp-Source: ANB0VdbWRCA7zaGg05L2Z5A9i5eYSXhgEy39bsro1n6I33TlrvUZqyr4rLr/ncs92UfMDbgadhB1EA==
X-Received: by 2002:a63:5815:: with SMTP id m21-v6mr23362338pgb.78.1535923739925; Sun, 02 Sep 2018 14:28:59 -0700 (PDT)
Received: from [192.168.50.145] (c-73-158-246-48.hsd1.ca.comcast.net. [73.158.246.48]) by smtp.gmail.com with ESMTPSA id h12-v6sm22643730pfo.135.2018.09.02.14.28.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Sep 2018 14:28:59 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: bruno.decraene@orange.com, "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" <draft-ietf-spring-segment-routing-ldp-interop@ietf.org>, Rob Shakir <robjs@google.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "spring@ietf.org" <spring@ietf.org>, The IESG <iesg@ietf.org>
References: <152951284387.28600.11874107921186798735.idtracker@ietfa.amsl.com> <c8beb644-253e-bcfe-7fd0-1d46a5b04d81@gmail.com> <22642_1531139781_5B4356C5_22642_217_1_53C29892C857584299CBF5D05346208A47AE54BA@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180709225252.GD59001@kduck.kaduk.org> <31682_1531226969_5B44AB59_31682_103_1_53C29892C857584299CBF5D05346208A47AE73C4@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180710141101.GP59001@kduck.kaduk.org> <bd0ffaf1-b0b2-3b9d-85a3-75a675c4c7bb@gmail.com> <20180726202715.GA91950@kduck.kaduk.org>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <b3f73e73-32be-87d2-8b84-e7612aec0246@gmail.com>
Date: Sun, 02 Sep 2018 14:28:58 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180726202715.GA91950@kduck.kaduk.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/a7RBFqngbSvz2xm4zRYK5s3K5qs>
Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Sep 2018 21:29:06 -0000
It seems like it was some editing error I uploaded version 15 and oput back the parapgraph Ahmed On 7/26/18 1:27 PM, Benjamin Kaduk wrote: > Hi Ahmed, > > Thanks for posting the update (and sorry for only getting to it now). > > The two specific points I raised in my DISCUSS ballot are properly > addressed, but before I go clear that I was hoping you could help me > remember why the following text was removed when going from -13 to -14: > > [...] Because this document recognizes that > miscofiguration and/or programming may result in false or conflicting > label binding advertisements, thereby compromising traffic > forwarding, the document recommends strict configuration/ > programmability control as well as montoring the SID advertised and > log/error messages by the operator to avoid or at least significantly > minimize the possibility of such risk. > > I couldn't find anything in my email history that helped jog my memory. > > Thanks, > > Benjamin > > On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote: >> Hi, >> >> I just posted version 14 >> https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt >> >> Thanks >> >> Ahmed >> >> >> >> On 7/10/18 7:11 AM, Benjamin Kaduk wrote: >>> Hi Bruno, >>> >>> Thanks for the additional clarifications in the suggested text -- it looks >>> good to me, so you and Ahmed should please go ahead with it (once >>> submissions open up again). >>> >>> -Benjamin >>> >>> On Tue, Jul 10, 2018 at 12:49:28PM +0000, bruno.decraene@orange.com wrote: >>>> Hi Benjamin, >>>> >>>> Thanks for the discussion. >>>> Please see inline [Bruno2] >>>> >>>>> From: Benjamin Kaduk [mailto:kaduk@mit.edu] >>>> > Sent: Tuesday, July 10, 2018 12:53 AM >>>> > On Mon, Jul 09, 2018 at 12:36:20PM +0000, bruno.decraene@orange.com wrote: >>>> > > Hi Benjamin, >>>> > > >>>> > > Thanks for your comments. >>>> > > Please see inline another addition to Ahmed's answer. [Bruno] >>>> > > >>>> > > > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] >>>> > > > Sent: Monday, July 09, 2018 2:30 AM >>>> > > > >>>> > > > Hi >>>> > > > Thanks for the review >>>> > > > >>>> > > > See reply to the comment at #Ahmed >>>> > > > >>>> > > > Ahmed >>>> > > > >>>> > > > >>>> > > > On 6/20/18 9:40 AM, Benjamin Kaduk wrote: >>>> > > > > Benjamin Kaduk has entered the following ballot position for >>>> > > > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss >>>> > > > > >>>> > > > > When responding, please keep the subject line intact and reply to all >>>> > > > > email addresses included in the To and CC lines. (Feel free to cut this >>>> > > > > introductory paragraph, however.) >>>> > > > > >>>> > > > > >>>> > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> > > > > for more information about IESG DISCUSS and COMMENT positions. >>>> > > > > >>>> > > > > >>>> > > > > The document, along with other ballot positions, can be found here: >>>> > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > DISCUSS: >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > >>>> > > > > I may be missing something, but I don't see anything that says whether the >>>> > > > > preference field introduced in Section 3.2.3 uses larger values or smaller >>>> > > > > values for more-preferred SRMSes. >>>> > > > #Ahmed: >>>> > > > If I understand this statement correctly, the concern is about which >>>> > > > label(s) get assigned to which prefix(es). This concern is addressed as >>>> > > > follows >>>> > > > >>>> > > > From the MPLS architecture point of view, there is nothing wrong in >>>> > > > having multiple labels for the same prefix. Segment routing in general >>>> > > > and this document in particular did not introduce this behavior nor did >>>> > > > they prohibit/restrict/relax it. For example, an implementation that >>>> > > > allows the operator to locally assign multiple local labels to the same >>>> > > > prefix may continue to apply this behavior whether the platform supports >>>> > > > segment routing or not, in which case it is up to the implementation >>>> > > > and/or the configuration affecting the MPLS forwarding plane to specify >>>> > > > how to behave when multiple labels are assigned to the same prefix. Such >>>> > > > behavior is a general MPLS behavior that outside the scope of and is not >>>> > > > modified by segment routing. >>>> > > > >>>> > > > However the opposite, where the same label gets assigned to multiple >>>> > > > prefixes resulting in label collision is problematic. This document >>>> > > > prohibits label collision resulting from the use of SRMS (which is >>>> > > > introduced by this document) in the first bullet starting at the 3rd >>>> > > > line of page 12: >>>> > > > "- If there is an incoming label collision as specified in >>>> > > > [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified >>>> > > > in [I-D.ietf-spring-segment-routing-mpls] to resolve the >>>> > > > collision."" >>>> > > > >>>> > > > > >>>> > > > > >>>> > > > > The introduction of the SRMS is also introducing a new way for a protocol >>>> > > > > participant to make claims about route prefixes directed at "third parties" >>>> > > > > (non-MS, non-MC routers). While routing protocols in general do require high >>>> > > > > levels of trust in all participants in order for proper routing to occur, this >>>> > > > > addition seems to create a "first among equals" situation that could be called >>>> > > > > out more clearly in the security considerations. (I do appreciate that the >>>> > > > > requirement for preferring SIDs advertised in prefix reachability >>>> > > > > advertisements over those advertised in mapping server advertisements does help >>>> > > > > alleviate some of the risk.) >>>> > > >>>> > > [Bruno] >>>> > > 1) As the SID attached to the prefix reachability is more preferred than the SID advertised by the >>>> > SRMS, I would kind of argue that the SRMS is more "last among equals" :-) >>>> > > 2) I agree that routing protocols, especially Link State Internal Routing Protocols, do require high >>>> > levels of trusts among participants. In particular, please note that any node can already advertise >>>> > any IP prefix (with any attached SID), and with any metric/cost, hence attracting the traffic. In this >>>> > regards, I don't really see an increased risk in IGP routing. >>>> > >>>> > I don't really see an increased risk per se, either (since all routers can >>>> > break routing in all sorts of ways), but I do see a new mechanism by which >>>> > certain routers can cause routing breakage. So I was thinking "first among >>>> > equals" in terms of "more ways to break things", not "can break things with >>>> > a larger magnitude of breakage". You are right that the preference order >>>> > that Ahmed described does mean that this new "mechanism for breakage" is >>>> > only applicable when there are no explicit prefix-SID advertisements >>>> > received via the IGP. So in that sense this new mechanism for breakage is >>>> > "last among equals", as you say, because it can only take effect if the IGP >>>> > leaves room for it. >>>> >>>> [Bruno2] Ack; I believe we are in sync. >>>> >>>> > > 3) I agree that SRMS allows for a "centralized" SID advertisement. I personally don't feel that this >>>> > is more risky than a "centralized" BGP Route Reflector. However, I'm not against raising this in the >>>> > security consideration section. >>>> > > Please see below a proposed text. Please comment/propose text as required. >>>> > > >>>> > > OLD: >>>> > > This document introduces another form of label binding >>>> > > advertisements. The security associated with these advertisement is >>>> > > part of the security applied to routing protocols such as IS-IS >>>> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of >>>> > > cryptographic authentication mechanisms. This document also >>>> > > specifies a mechanism by which the ill effects of advertising >>>> > > conflicting label bindings can be mitigated. >>>> > > >>>> > > NEW: >>>> > > This document introduces another form of label binding >>>> > > advertisements. The security associated with these advertisements is >>>> > > part of the security applied to routing protocols such as IS-IS >>>> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of >>>> > > cryptographic authentication mechanisms. >>>> > > This form of advertisement is more centralized, on behalf of the node advertising the IP >>>> > reachability. >>>> > > This document also >>>> > > specifies a mechanism by which the ill effects of advertising >>>> > > conflicting label bindings can be mitigated. In particular, advertisements from the node >>>> > advertsising the IP reachability is more preference than the centralized one. >>>> > >>>> > I think that's enough to resolve my DISCUSS point. I would prefer if there >>>> > was a little bit more text, such as "more centralized, on behalf of the >>>> > node advertising the IP reachability, which presents a different risk >>>> > profile than existing mechanisms for distributing label bindings", but your >>>> > version does cover the key point. >>>> >>>> [Bruno2] ok. Proposed NEW2: >>>> >>>> This document introduces another form of label binding >>>> advertisements. The security associated with these advertisements is >>>> part of the security applied to routing protocols such as IS-IS >>>> [RFC5304] and OSPF [RFC5709] which both optionally make use of >>>> cryptographic authentication mechanisms. >>>> This form of advertisement is more centralized, on behalf of the node advertising the IP reachability, which presents a different risk profile. >>>> This document also >>>> specifies a mechanism by which the ill effects of advertising >>>> conflicting label bindings can be mitigated. In particular, advertisements from the node advertising the IP reachability is more preferred than the centralized one. >>>> >>>> >>>> >>>> In short, I used your proposed text but removed " than existing mechanisms for distributing label bindings" as this could be read as "LDP". We could add more text to distinguish, but IMO the current text seems fine. >>>> >>>> >>>> > (And to be clear, I am not trying to say >>>> > that the centralized risk is better or worse in all cases; it's just >>>> > different, so we should call that out to the reader and inform their decision >>>> > making.) >>>> >>>> [Bruno2] In sync. I agree with you that we should call that out to the reader and inform their decision making. Thanks for bringing the comment. >>>> I'll work with Ahmed, to have the draft reflect this, as he has the pen. >>>> >>>> Thanks, >>>> Bruno >>>> >>>> >>>> > Thanks, >>>> > >>>> > Benjamin >>>> > >>>> > > >>>> > > Thanks, >>>> > > --Bruno >>>> > > >>>> > > > #Ahmed: >>>> > > > If I understand your comment, the concern is about >>>> > > > "first-come-first-serve" behavior. I believe this concern is addressed >>>> > > > as follows >>>> > > > (1) The sentence starting at the fourth line of the second paragraph in >>>> > > > page 10 says: >>>> > > > For a given prefix, if an MC receives an SR mapping advertisement >>>> > > > from a mapping server and also has received a prefix-SID >>>> > > > advertisement for that same prefix in a prefix reachability >>>> > > > advertisement, then the MC MUST prefer the SID advertised in the >>>> > > > prefix reachability advertisement over the mapping server >>>> > > > advertisement i.e., the mapping server advertisment MUST be ignored >>>> > > > for that prefix. >>>> > > > >>>> > > > (2) The last bullet at the bottom of page 11 says: >>>> > > > - For any prefix for which it did not receive a prefix-SID >>>> > > > advertisement, the MCC applies the SRMS mapping advertisments with >>>> > > > the highest preference. >>>> > > > >>>> > > > (3) The first bullet near the top pf page 12 says: >>>> > > > - If there is an incoming label collision as specified in >>>> > > > [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified >>>> > > > in [I-D.ietf-spring-segment-routing-mpls] to resolve the >>>> > > > collision. >>>> > > > >>>> > > > So for the same set of received advertisements (SRMS advertisements, >>>> > > > prefix-SID advertisements, or combination of both), the same set of >>>> > > > labels will be assigned to the same prefix. As mentioned in my previous >>>> > > > comments, if multiple labels get assigned to the same prefix, the >>>> > > > behavior is not related to segment routing >>>> > > > >>>> > > > Regarding placing a comment in the security section, IMO a specification >>>> > > > of which advertisement(s) to use when receiving multiple (conflicting or >>>> > > > non-conflicting) advertisements has nothing to do with security. It is >>>> > > > an externally visible protocol(s) behavior that should be specified in >>>> > > > the sections covering the protocol(s) themselves rather than security >>>> > > > consideration of the protocol(s). >>>> > > > >>>> > > > But if you still think there is a need to mention something in the >>>> > > > security section, a suggestion from your side will be greatly appreciated . >>>> > > > > >>>> > > > > >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > COMMENT: >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > >>>> > > > > I support Alissa's suggestion about the text covering cryptographic authentication. >>>> > > > #Ahmed: I modified the statement as Alissa suggested in version 14 that >>>> > > > will be published in the next 1-2 days >>>> > > > > >>>> > > > > "[100,300]" and "(100,200)" are each used as an example SRGB. In >>>> > > > > some contexts the round versus square brackets indicate a >>>> > > > > distinction between "closed" (includes endpoints) and "open" (does >>>> > > > > not include endpoints) intervals. If there's no need to make such a >>>> > > > > distinction, I suggest standardizing one one format. >>>> > > > #Ahmed: I changed both of them to use [] in version because we mean >>>> > > > inclusive >>>> > > > > >>>> > > > > As was mentioned in the secdir review, it would be good to expand FEC and LFA on first >>>> > usage. >>>> > > > #Ahmed: Corrected in version 14 that will be published in the next 1-2 days >>>> > > > > >>>> > > > > Section 1 >>>> > > > > >>>> > > > > Section 2 describes the co-existence of SR with other MPLS Control >>>> > > > > Plane. [...] >>>> > > > > >>>> > > > > nit: "other MPLS Control Plane" seems to be an incomplete compound noun >>>> > > > > -- is it other control plane technologies that are being considered? >>>> > > > #Ahmed: I added "protocols" in version 14 to clarify that >>>> > > > > >>>> > > > > Section 2 >>>> > > > > >>>> > > > > Note that this static label allocation capability of the label >>>> > > > > manager exists for many years across several vendors and hence is not >>>> > > > > new. Furthermore, note that the label-manager ability to statically >>>> > > > > allocate a range of labels to a specific application is not new >>>> > > > > either. [...] >>>> > > > > >>>> > > > > nits: "has existed", "label-manager's ability". >>>> > > > #Ahmed: Corrected (thanks a lot) >>>> > > > > >>>> > > > > Section 2.1 >>>> > > > > >>>> > > > > MPLS2MPLS refers the forwarding behavior where a router receives an >>>> > > > > labeled packet and switches it out as a labeled packet. Several >>>> > > > > >>>> > > > > nit: "refers to", "a labeled packet" >>>> > > > #Ahmed: Corrected >>>> > > > > >>>> > > > > Section 3.2 >>>> > > > > >>>> > > > > This section defines the Segment Routing Mapping Server (SRMS). The >>>> > > > > SRMS is a IGP node advertising mapping between Segment Identifiers >>>> > > > > (SID) and prefixes advertised by other IGP nodes. The SRMS uses a >>>> > > > > dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is protocol >>>> > > > > specific and defined in [I-D.ietf-isis-segment-routing-extensions], >>>> > > > > [I-D.ietf-ospf-segment-routing-extensions], and >>>> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. >>>> > > > > >>>> > > > > nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is a >>>> > > > > better parenthetical? >>>> > > > #Ahmed: Corrected in the next version >>>> > > > > >>>> > > > > The example diagram depicted in Figure 3 assumes that the operator >>>> > > > > configures P5 to act as a Segment Routing Mapping Server (SRMS) and >>>> > > > > advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103) >>>> > > > > and (PE4, 104). >>>> > > > > >>>> > > > > nit: I think this is Figure 2. >>>> > > > #Ahmed: Corrected in the next version >>>> > > > > >>>> > > > > Section 3.2.1 >>>> > > > > >>>> > > > > [...] Examples >>>> > > > > of explicit prefix-SID advertisment are the prefix-SID sub-TLVs >>>> > > > > defined in ([I-D.ietf-isis-segment-routing-extensions], >>>> > > > > [I-D.ietf-ospf-segment-routing-extensions], and >>>> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). >>>> > > > > >>>> > > > > Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat) >>>> > > > > be appropriate for inclusion in this list? >>>> > > > > >>>> > > > > for that prefix. Hence assigning a prefix-SID to a prefix using the >>>> > > > > SRMS functionality does not preclude assigning the same or different >>>> > > > > prefix-SID(s) to the same prefix using explict prefix-SID >>>> > > > > advertisement such as the aforementioned prefix-SID sub-TLV. >>>> > > > #Ahmed: The SRMS functionality is specific to IGPs as mentioned in the >>>> > > > second sentence of the second paragraph in Section 3.2 >>>> > > > > >>>> > > > > nit: I think the aforementioned things were a list, so "sub-TLVs" plural >>>> > > > > would be appropriate. >>>> > > > > >>>> > > > > Including the name for IS-IS TLV 135 might be helpful for the >>>> > > > > reader. >>>> > > > > >>>> > > > #Ahmed: Corrected as suggested in the next version >>>> > > >>>> > > >>>> > > >>>> > ________________________________________________________________________________ >>>> > _________________________________________ >>>> > > >>>> > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou >>>> > privilegiees et ne doivent donc >>>> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par >>>> > erreur, veuillez le signaler >>>> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant >>>> > susceptibles d'alteration, >>>> > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>> > > >>>> > > This message and its attachments may contain confidential or privileged information that may be >>>> > protected by law; >>>> > > they should not be distributed, used or copied without authorisation. >>>> > > If you have received this email in error, please notify the sender and delete this message and its >>>> > attachments. >>>> > > As emails may be altered, Orange is not liable for messages that have been modified, changed >>>> > or falsified. >>>> > > Thank you. >>>> > > >>>> >>>> _________________________________________________________________________________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>>
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… bruno.decraene
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… bruno.decraene
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… bruno.decraene
- [spring] Benjamin Kaduk's Discuss on draft-ietf-s… Benjamin Kaduk
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Ahmed Bashandy
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Ahmed Bashandy
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Ahmed Bashandy
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… bruno.decraene
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… bruno.decraene
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Alvaro Retana
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Ahmed Bashandy
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Ahmed Bashandy
- Re: [spring] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk