Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-rsvp-shared-labels-07: (with DISCUSS and COMMENT)
Vishnu Pavan Beeram <vishnupavan@gmail.com> Fri, 18 January 2019 13:43 UTC
Return-Path: <vishnupavan@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 44FA0129AB8; Fri, 18 Jan 2019 05:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 sUvwvho5MPHb; Fri, 18 Jan 2019 05:43:42 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 31ECA126C7E; Fri, 18 Jan 2019 05:43:42 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id a14so6371409plm.12; Fri, 18 Jan 2019 05:43:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3XSZx/9aIVtBgiUQikB79F1Mht+bHBy1HBDK+5uVM50=; b=azcFrx8eBEECL2E4gxGs+VL39mC2MM49gTGscfRrE0lI/8EMzRXGumtaSPVt7z6jaX J/W79s2qSpqEGN6RCRpWSXHt3ITi3Op3zqKzaEQTp65ML1j/bvDrCCsUlg0ssyG6w1hE 1yYg4tlzKgYzuvv1FA3H1jXKCmnxymI1IjYoKDVcbyrwjZdd99lbUCxlandFEELF/ehv FNWbabn+nN6xOizMuFJeqJ8TlXp+eD0apP7QIpPnPa9RMI4MkU9Uglw9sAnjxTQxInEn xLSPQ9rZYuOeBDHgIPs7xUcoElfVCNjg2yrCMWmSsxxco7Z27ODb6TOdwfI+606OZ3EG LKTQ==
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=3XSZx/9aIVtBgiUQikB79F1Mht+bHBy1HBDK+5uVM50=; b=D/XfUkGyKEbtFvlBI71W2uxcKR6Nu5zORYjTMgxKwLhlbz5tM/ujSEzA0ZfYHagsdC KMyGsXfuuqu8NEw2OYlxWBrXQKovsqprtAULXQqm5RU27cn2fjqwKCIc7lO3+tEEX5Pf kcoi9l0OkfCGjfrLIgtynii/yi2lolrRMg2QrchIY9j0cs0TkGZZ9L+5aB8JpSbYsGs/ YCrxvRK7u4Y0Xm5jp9PhbibXB4RWK5utR9IU9FA2krpm+7ld3C4mnc8QiNv8aBFFnk73 amXK7QinxOzo13m9XP7Y3MvS48Mf7/xhm1ijCiTPRaj8Wmzf/mkRpDTVt4bekVCG2mp1 MgNQ==
X-Gm-Message-State: AJcUukdfXyIL7ZEDAhlOteLYH7rF/yP47dhfntc2GwYsQsZ7I+UI2TdF eX+z5uJHJCEQHAwX0pBlaVTKMlCKgIoADHxC03Q=
X-Google-Smtp-Source: ALg8bN6CsZWPu/OhDU1vrC/4DLj8FZ4PiegKnlqWxIZVw7XjMW+H+zwRnMKzg6jTh3CALiPNChuUhsOBycZ4A76i2G8=
X-Received: by 2002:a17:902:f81:: with SMTP id 1mr18690453plz.174.1547819021403; Fri, 18 Jan 2019 05:43:41 -0800 (PST)
MIME-Version: 1.0
References: <154508592591.4271.12094992121838897393.idtracker@ietfa.amsl.com> <CA+YzgTtfVDObu90XrVporj9UU_RYfK1Qs=P5XfUzn-NXLPOckg@mail.gmail.com> <CAMMESsyjOGXkfx9VzepDTwWdVNqDwyNMmG==S9vf4r3mUBz+Tg@mail.gmail.com> <CA+YzgTu3Q69-V-M0d8XtnCa7xsRYjdPCiSgvOXKpOshyeOCGQg@mail.gmail.com>
In-Reply-To: <CA+YzgTu3Q69-V-M0d8XtnCa7xsRYjdPCiSgvOXKpOshyeOCGQg@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Fri, 18 Jan 2019 08:43:28 -0500
Message-ID: <CA+YzgTtbKfWdc9b_+jasOOegGs+PUL3v6CXO=fO95AQophdJaQ@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: mpls-chairs@ietf.org, IETF MPLS List <mpls@ietf.org>, draft-ietf-mpls-rsvp-shared-labels@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f28a33057fbbb20f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/6oVY0hREgMd-ZynAvqQVtkxR7ko>
Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-rsvp-shared-labels-07: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 18 Jan 2019 13:43:45 -0000
Alvaro, Hi! We just uploaded a new rev (-08) for this draft. Please do go through the diffs ( https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-shared-labels-08) and let us know if all your comments have been addressed. Regards, Pavan (on behalf of the authors) On Thu, Dec 20, 2018 at 10:18 AM Vishnu Pavan Beeram <vishnupavan@gmail.com> wrote: > Alvaro, Hi! > > > > Please see inline (prefixed [Pavan]). > > > > Regards, > > Pavan > > On Thu, Dec 20, 2018 at 8:06 AM Alvaro Retana <aretana.ietf@gmail.com> > wrote: > >> On December 20, 2018 at 7:15:52 AM, Vishnu Pavan Beeram ( >> vishnupavan@gmail.com) wrote: >> >> Pavan: >> >> Hi! >> >> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> A significant portion of this specification depends on knowing the label >>> stack >>> depth limits in the network, but §5.2 declares the mechanism out of >>> scope: >>> >>> In order to accurately pick >>> the delegation hops, the ingress needs to be aware of the label stack >>> depth push limit of each of the transit LSRs prior to initiating the >>> signaling sequence. The mechanism by which the ingress or controller >>> (hosting the path computation element) learns this information is >>> outside the scope of this document. >>> >>> I think that not defining the mechanism in this document is ok -- but not >>> having one means that important parts of this specification can't work. >>> Please >>> point at where such a mechanism is specified, or at least provide >>> examples. >>> >>> The Shepherd's writeup says that "implementation plans and >>> implementations" are >>> known so I think that this should be an easy point to address. >>> >>> >>> >> [VPB] The specification discusses a couple of delegation options -- the >> explicit delegation option (Section 5.2) and the automatic delegation >> option (Section 5.3). The explicit delegation option is the only one that >> needs the ingress or the controller to be aware of the label stack depth >> push limit of each of the transit LSRs prior to signaling. This information >> is not needed when the automatic delegation option is employed -- the >> limitations of each transit node are taken into account while picking the >> delegation hops during the initial signaling sequence. >> >> >> >> For the explicit delegation option, an implementation may choose to >> employ any of the following mechanisms to learn the label stack depth push >> limit of each LSR in the network -- ISIS (RFC8491), OSPF (RFC8476), >> BGP-LS (draft-ietf-idr-bgp-ls-segment-routing-msd), PCEP >> (draft-ietf-pce-segment-routing), local config (just set a global limit), >> netconf/restconf/grpc using the data-model specified in >> draft-ietf-teas-yang-sr-te-topo. >> >> >> >> Please see if the addition of the following statement to the end of the >> first paragraph in Section 5.2 addresses your concern: >> >> >> >> "Examples of such a mechanism are specified in RFC8491 and RFC8476." >> >> These are fine examples, and they would satisfy the point above. >> >> However, they raise an additional one. rfc8491 has a very specific >> definition of what the Base MPLS Imposition MSD is, but that definition may >> not match what is discussed here. The intent may be the same, but the text >> is different, and given the extensive discussion prior to the publication >> of rfc8491, I want to make sure that we are in fact talking about the same >> thing: "label stack depth push limit” doesn’t directly map to "the total >> number of MPLS labels that can be imposed, including all >> service/transport/special labels” [rfc8491]. I note that this document >> specifically mentions just transport labels. >> >> If the definition of the BMI-MSD is what is expected in this document, >> please explicitly say so. If not, then I think that we would need to >> define a new MSD-Type for the suggestions above to be applicable. >> > [Pavan] The “label stack depth push limit” is the same as what is referred > to as the BMI-MSD in RFC8491. We will make that explicit. > >> >> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> (1) §5.3.1: "The ETLD MUST be decremented at each non-delegation transit >>> hop by >>> either 1 or some appropriate number based on the limitations at that >>> hop." >>> What is "some appropriate number"? Please be specific. Can you provide >>> an >>> example? >>> >> >> [VPB] We did discuss this during the WG adoption poll. The option to >> decrement the ETLD by "some appropriate number" was added to let the >> transit hop cater to the scenario where the ETLD value in the received PATH >> message is larger than the maximum number of labels in the stack that the >> hop can handle. In other words, the "limitations at that hop" reference in >> the text above need not be limited to just the "push limitation", it could >> include the "read limitation" as well. Consider a transit hop that can read >> only 6 labels and has a local policy that mandates it to not receive any >> more transport labels in the stack than it can possibly read. If this hop >> receives an ETLD of 8 from the previous-hop, then it could adjust the >> outgoing ETLD to 5 (thus ensuring that it can never receive any more >> label-stack-entries than it can actually read). >> >> It would be great if you added an explanation like that in the document. >> > [Pavan] Okay. We’ll add that. > > >> >> ... >> >> (4) §9.2: "When a node that does not cater to the mandate receives a Path >>> message carrying the LSP_REQUIRED_ATTRIBUTES object with this flag set, >>> it MUST >>> send a PathErr message..." Why would a node "not cater to the >>> mandate"? I >>> imagine one instance being simply that the node doesn't support the >>> behavior >>> specified in this document. This document can't specify the behavior of >>> a node >>> that doesn't know what the new behavior is. If there are other reasons >>> for not >>> complying, please be explicit. >>> >> >> [VPB] There is a distinction that is being drawn here between an >> implementation that doesn’t understand this flag and an implementation that >> understands this flag but chooses not to cater to it (local policy). In the >> former scenario, it goes without saying that the regular processing rules >> for LSP_REQUIRED_ATTRIBUTES come into play ( >> https://tools.ietf.org/html/rfc5420#page-11) The text quoted above is >> for the latter scenario. A transit node may support both regular RSVP-TE >> LSPs and Segment Routed RSVP-TE LSPs. Local policy may determine if the >> node should cater to both types or just one type. >> >> >> >> Please see if the following change makes things clear: >> >> >> >> OLD: >> >> When a node that does not cater to the mandate >> >> receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object >> >> with this flag set, it MUST send a PathErr message with an error code >> >> of 'Routing Problem (24)' and an error value of 'TE link label usage >> >> failure (TBD3)'. >> >> >> >> NEW: >> >> When a node that recognizes this flag but does not cater to the >> mandate >> >> receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object >> >> with this flag set, it MUST send a PathErr message with an error code >> >> of 'Routing Problem (24)' and an error value of 'TE link label usage >> >> failure (TBD3)'. >> >> >> >> ** >> >> I think it would be clearer if you mentioned the reason in the text: >> local policy. Maybe s/does not cater/does not cater because of local policy >> > [Pavan] Agree. We’ll make the suggested change. > >> >> (4a) Note that §9.4 uses a similar construct: "If the hop is not able to >>> comply >>> with this mandate...", which implies that there may be a reason other >>> than not >>> supporting the functionality. Here as well, what are examples of >>> reasons for >>> the node not being able to comply? >>> >> >> [VPB] The previous response should have provided some clarity on this. >> Please note that as per 9.2, a node that recognizes the "TE Link Label" >> Attribute Flag MUST also recognize the other Attribute Flags defined in >> this document. Please see if the following change makes things clear: >> >> >> >> OLD: >> >> If the hop is not able to comply with this mandate, it >> >> MUST send a PathErr message with an error code of 'Routing Problem >> >> (24)' and an error value of 'Label stack imposition failure (TBD4)'. >> >> >> >> NEW: >> >> If the hop recognizes this flag but is not able to comply with this >> mandate, it >> >> MUST send a PathErr message with an error code of 'Routing Problem >> >> (24)' and an error value of 'Label stack imposition failure (TBD4)'. >> >> >> >> ** >> >> Again, mentioning the reason would make it clearer. >> > [Pavan] Okay. We’ll make the suggested change. > >> >> (5) §9.4: "If the transit hop does not support this flag, it MUST act as >>> if it >>> does not support TE link labels." I'm not sure if this text refers to a >>> node >>> not supporting this specification (see above), or to a neighbor of that >>> node. >>> In either case, what does "act as if it does not support TE link labels" >>> mean? >>> How can "acting" be Normatively enforced? Does that mean that if the >>> node >>> supports this specification it must stop doing so (at least for the >>> LSP)? ?? >>> >> >> [VPB] This refers to a transit node that supports the "TE Link Label" >> Attribute flag but does not support the automatic delegation functionality >> (it does recognize the flag though). Such nodes would support "TE Link >> Labels" as long as "automatic delegation" is not also requested. But if >> "automatic delegation" is also requested, they would act as if they don’t >> support "TE Link Labels" and use regular labels. >> >> >> >> Would the following change make things clear? >> >> >> >> OLD: >> >> If the transit hop does not support this flag, it MUST act as if it does >> not support TE link labels >> >> >> >> NEW: >> >> If the transit hop does not support this flag, it MUST act as if it does >> not support TE link labels and use regular labels. >> >> ** >> >> Maybe s/support this flag/support this functionality >> >> I still think that “acting” can’t be enforced. Maybe s/MUST act as if it >> does not support TE link labels and use regular labels/MUST NOT use TE link >> labels and use regular labels instead >> >> >> [Pavan] Okay. We’ll make the suggested change. > >> ... >> >> (5b) Note that the same phrase (act as if...) is also used in §5.3.1. >>> >> >> [VPB] The previous responses should have made this clear. >> >> See above… >> >> >> Thanks!! >> >> Alvaro. >> >
- [mpls] Alvaro Retana's Discuss on draft-ietf-mpls… Alvaro Retana
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Vishnu Pavan Beeram
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Vishnu Pavan Beeram
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Vishnu Pavan Beeram
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Vishnu Pavan Beeram
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Vishnu Pavan Beeram
- Re: [mpls] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana