Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-rsvp-shared-labels-07: (with DISCUSS and COMMENT)
Vishnu Pavan Beeram <vishnupavan@gmail.com> Thu, 20 December 2018 15:18 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 49130131120; Thu, 20 Dec 2018 07:18:52 -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 f9Ppoz7H3ZNy; Thu, 20 Dec 2018 07:18:49 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 29DA213111B; Thu, 20 Dec 2018 07:18:49 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id w4so1038264plz.1; Thu, 20 Dec 2018 07:18:49 -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=P747spllZ2Ks/kO5iWGY1mCWJgGlfw0yBNMkVY5dhw0=; b=j4H9hD2xQGdvGSXtfIf93AaPrE4qiTnWDvFi7z9FGzvVSDcqVzsg21jykiarMdVvi4 KsUjCtFcOSMYMBjrlCnt2UWOZCMEn9kAM5kR4tDYNDWkacLvycFC73hBF+6heVjPJo9Y E0PY69T0gcepu3DPzZjoA56tgLcRphGpbwN0oX/+b5Oa73uywwlnzpMprFMwRa08ZlUW tjt3rnl8QNL1tENkbLJaUKSEBqCKogCPyPVVwEGLtoQ2qu/DlVrnvJVn0U/fAW2MrT+Q cAt3rH+2iUp13mLZ5rGgxY7X9Pmim/7OmwDxbp87K6/52lifYSI36lKYKU9M4QFU/Q2K 3xyA==
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=P747spllZ2Ks/kO5iWGY1mCWJgGlfw0yBNMkVY5dhw0=; b=oL6klDzsMsasvcQI43E17BypHLv9bzszP//i9zeIug6+csfyzo2vt9F8X/DFbx0Dmd Nc3bXOfiw2Nwo8BFpdyAoda9tS/QeXJf7KDuTGfUDXm6CQWFWXvlR3Z2xwUBaI/5uRju 0nno+7rB9vp0QIWeyD28K6YFfFao3fhvvGI7l9eCRCF6UNr+aNN0CFWz5oN6wMqFCud6 HUzbOZmz9gvYwc3GuhEcZSq8FD39w1GJd0hVeowEz83XQyjzn95PY48FJfF5g0mAV4RI xlPtdtdJwuCsNNdWzN/0+bagco+ka1h5H9bxjwvigwJ7gINec7eJPR6mYVmYC+u+ubhw svbA==
X-Gm-Message-State: AA+aEWaW9JavKTC4+BcvCjlbOMAQCBw9mYBRiDR1INgMwkbyLMH7N6z7 u8YTgy7UqTnatqDBSOUpdpw2Oit4yJEtGS28n+4=
X-Google-Smtp-Source: AFSGD/VfRL71hw0Uqprx6UYMmkdQM0B8OGx+2hCwu7XdhpTdn1DipBMvNFVGNGnmNmhpgJEB184EuiICHQy8Jyp+2ak=
X-Received: by 2002:a17:902:f81:: with SMTP id 1mr23623388plz.174.1545319128523; Thu, 20 Dec 2018 07:18:48 -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>
In-Reply-To: <CAMMESsyjOGXkfx9VzepDTwWdVNqDwyNMmG==S9vf4r3mUBz+Tg@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Thu, 20 Dec 2018 10:18:36 -0500
Message-ID: <CA+YzgTu3Q69-V-M0d8XtnCa7xsRYjdPCiSgvOXKpOshyeOCGQg@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="000000000000b867c9057d75a564"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/e1C483zk3ouSKwXwa51Dm-5YR7U>
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: Thu, 20 Dec 2018 15:18:52 -0000
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