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.
>