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, 25 January 2019 23:17 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 D834E128AFB; Fri, 25 Jan 2019 15:17:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 okChOD5SStgP; Fri, 25 Jan 2019 15:17:43 -0800 (PST)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 F0E451288BD; Fri, 25 Jan 2019 15:17:42 -0800 (PST)
Received: by mail-pg1-x52d.google.com with SMTP id n2so4812458pgm.3; Fri, 25 Jan 2019 15:17: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=LN928hUwSGvXcwr6aWJ/WRJWhHR7MILT/sWckVyc85U=; b=bRbwQBXzp3BI1qcOy79Jge5dHjIeHAcvS6g53pDrbP+v/JXJ93Yjq7ICk9vMudBpIn 07f7wePBc/LXAh5FGidbgGyTIMVKQkQKlSJR9HJ6tzJ99n8jSDN1Sno1VVnVlNe0XuOT x1SKlU+nM9PYvCY7fCQw66SBUe+1nn5TU3v0STMuQ4tzM/K9FBp7z7ESDhtVnyGMzIE8 x4dc+2MZDks3w6JD9ohnRNjoElFBiOlS2WOak34Srucp5AjARC2mZTucdf+o5RQlnIZs d2OvWqiYbNWBn0yejtIPfXCrCXXj1jXzZhZ3kGuAMvMuUkRGRFCQy1UTEAbDO2xNxpxN AViw==
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=LN928hUwSGvXcwr6aWJ/WRJWhHR7MILT/sWckVyc85U=; b=smFgFCpKP+FVvLApD/UnrjgLVxwFjjIdlQvFTcnxkluwmvKM9/k6Ecb7Q6Fg7oPdl3 cyj/qp1hTr4qrKoAy4Tz/LVBvX2p8GITzaSExWhpBfFOfqy1hGQn0AuESgz5mRg66Lni m5oMZhdNNCH+Xh6cHP4zV2n5uBD4k6eKmDA0ocQo1bay8TBqlFQ/gMqPB52AQlEmzltg HiXnCxgYwZgxZH8h/rsmivNwj/a8FsKWpMg255xORC/d038HloA/Jn+ILCmRyvecoYuY zGYFCPKXGgt1t6cLBJH3QJJsq+6dHTG7OXlzVXD/7nYlLvXzVECo5hAf6D1WCg5r+Eot eDDw==
X-Gm-Message-State: AJcUukdE1rdPBbL3oQy21QV3VWsojcyp2DwwwqMP/UsO83n4I/gYW3hG 20W7TULQ3PQawjvF1n5hfM+7NxLbHWu62eensD8=
X-Google-Smtp-Source: ALg8bN6C6PNz3nC+K0cWBZDdAewUQNgp0AzGlWJxjL6wiJYNjCjKrSZFa//c9uQnJDFV8gFXg3StfssdZOCAqO1xJEM=
X-Received: by 2002:a63:a35c:: with SMTP id v28mr11584273pgn.205.1548458261996; Fri, 25 Jan 2019 15:17: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> <CA+YzgTtbKfWdc9b_+jasOOegGs+PUL3v6CXO=fO95AQophdJaQ@mail.gmail.com> <CAMMESsyKaerwgfxAWtXvhRF3guUituMFh280ZbHU1npd6W04xw@mail.gmail.com>
In-Reply-To: <CAMMESsyKaerwgfxAWtXvhRF3guUituMFh280ZbHU1npd6W04xw@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Fri, 25 Jan 2019 18:17:30 -0500
Message-ID: <CA+YzgTvXDnFv6HO69whU83TQsvcrDKo8H70aMLiTzGULDtCUkg@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="000000000000a7e75c058050888e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/dRCpEzi6_QsUmtn2vw--cgPi1XU>
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, 25 Jan 2019 23:17:46 -0000

Alvaro, Hi!

Thanks for reviewing the changes.
Please see inline..

Regards,
-Pavan

On Wed, Jan 23, 2019 at 4:52 PM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

Snipped..

> 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.
>>
>
> I see no place in the text where the relationship to the BMI-MSD is
> explicitly made.
>
> I see the text (in parenthesis) that you added in §5.3: "label stack depth
> push limit (number of MPLS labels that can be imposed)”, but that doesn’t
> make reference to either the BMI-MSD or rfc8491.  Also, the text added is
> not the complete definition.
>

Please see if the following changes address the concern.
**
In Section 5.2

OLD:

   In order to accurately pick
   the delegation hops, the ingress needs to be aware of the label stack
   depth push limit (number of MPLS labels that can be imposed) of each
   of the transit LSRs prior to initiating the signaling sequence.
   ...
   An example of such a mechanism is specified in [RFC8491].

NEW:
   In order to accurately pick
   the delegation hops, the ingress needs to be aware of the label stack
   depth push limit (total number of MPLS labels that can be imposed,
   including all service/transport/special labels) of each of the
   transit LSRs prior to initiating the signaling sequence.
   ...
   An example of such a mechanism is specified in [RFC8491] (BMI-MSD
   advertisement).
**

>> All this would make rfc8491 a Normative reference.

Would it? Please note that the “explicit delegation” can be implemented
without needing to implement any of the standard BMI-MSD learning
technologies. The RFC8491 mechanism is just one option. As stated earlier,
an implementation may choose to employ any of the following mechanisms
besides 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.




>
> Thanks!
>
> Alvaro.
>