Return-Path: 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 B2433130F9C; Thu, 31 Jan 2019 13:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 FNkyn5l2AYPT; Thu, 31 Jan 2019 13:45:48 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 205CC130F97; Thu, 31 Jan 2019 13:45:48 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id w13so4075983oiw.9; Thu, 31 Jan 2019 13:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xmYXiQFatfYnaRJ9V6KantItbgOk7NKO8x2XJ39lsEQ=; b=HjU0vMeErcl+tRHF9/Vbd1cGEM3NoIu24GeuMzNBAQkKJm4lhipzyHfEAe/cPrb/A6 9UO0NkSUGcmZIpV0I1P5IUtsa7JA6Xz08UPfAmYYqYIqicA9kiD4B/t+ZOH5p7xQw84j hwPTzE20dcdSSJlJ/CN3polkaDNhbLK77Fh35rOcdwONY+Q8rLYwjvZiBV60Tyou3t7y /UjJYBuuWz1eIiwcmlpSkOTYl8k3yP8pPEYlfzPYhGch8SnC/ma0BNwAhdRpYiiPY6El EpNDjqw41FSWqO+XOGP+eIFkjuIC2CM34VmWnOCb7Xae8A9AHUXVi7Pw762eTeJnAYQ4 dqOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xmYXiQFatfYnaRJ9V6KantItbgOk7NKO8x2XJ39lsEQ=; b=mB8P+Oq+DxCFTMDNqyYAPOOlD4WmMkZt1JayC/9Uhwz5s/O0ddFLkoHSoH5PDfHmVu uPsaFx+B+cXbTBm8oLfJt71yP9JVctVxbE/NBTOlNG/BvFWgaeeoOW9BsBvt3bHYPfXS KPpGHU5gqPbXST/ioI9wqHTKyqPPRfomK+70EPS9vb59FHoKtAXqPojHBPiQBDTfRv5E 54zcH96SJK7o7ouSGiQNgArXr08J1OmfGIFw9dLnFZonEvT0qSnm6kgX2/8HNsD+jf99 GTgAVOX3VwkAaafiBgczQ0/4/jZ+iyUAHVKzWS83PFRXmx6trG9dIVKt1JT15QJiRNu5 p3Vg== X-Gm-Message-State: AJcUukcDB0WnueiIzt8GgrasrhA092Z+6HFXMYkQiUciW5hxd8kuUb3x 5lwvXplsnyFXjvhpqmnLE66FON04fC0FXBm84ts= X-Google-Smtp-Source: AHgI3IY/X5lBkYeXSIA8WXelohR9i7Yt/0PznlOJLthxbEa+Ght8qm/EB1tf7Z0P1isZKL9J8ZPvQQ80FZetwBlfc1c= X-Received: by 2002:aca:1b13:: with SMTP id b19mr16190482oib.215.1548971147387; Thu, 31 Jan 2019 13:45:47 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 31 Jan 2019 22:45:46 +0100 From: Alvaro Retana In-Reply-To: References: <154508592591.4271.12094992121838897393.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Thu, 31 Jan 2019 22:45:46 +0100 Message-ID: To: Vishnu Pavan Beeram Cc: mpls-chairs@ietf.org, IETF MPLS List , draft-ietf-mpls-rsvp-shared-labels@ietf.org, The IESG Content-Type: multipart/alternative; boundary="00000000000001e87d0580c7f3ee" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 21:45:50 -0000 --00000000000001e87d0580c7f3ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 25, 2019 at 6:17:42 PM, Vishnu Pavan Beeram ( vishnupavan@gmail.com) wrote: Pavan: ... On Wed, Jan 23, 2019 at 4:52 PM Alvaro Retana 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 publicati= on >>> of rfc8491, I want to make sure that we are in fact talking about the s= ame >>> thing: "label stack depth push limit=E2=80=9D doesn=E2=80=99t directly = map to "the total >>> number of MPLS labels that can be imposed, including all >>> service/transport/special labels=E2=80=9D [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 =E2=80=9Clabel stack depth push limit=E2=80=9D is the same a= s 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 =C2=A75.3: "label stack= depth > push limit (number of MPLS labels that can be imposed)=E2=80=9D, but that= doesn=E2=80=99t > 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 =E2=80=9Cexplicit delegation=E2=80=9D 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 =E2=80=94 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. I would have preferred if a Normative reference was made to BMI-MSD to avoid any confusion (vs copying the definition here). That=E2=80=99s were = I think that rfc8491 would be Normative; not in the mechanism, but in the definition. In any case, I guess the way you wrote it above is ok as well. I=E2=80=99l= l clear the DISCUSS when you publish an update. Thanks!! Alvaro. --00000000000001e87d0580c7f3ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 25, 2019 at 6:17:42 PM, Vishnu Pavan = Beeram (vishnupavan@gmail.com)= wrote:

=
Pavan:


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

Snipped..
=
=

These are fine examples, and they wo= uld satisfy the point above.

However, they raise an additional one. =C2=A0rfc8491 has a very specif= ic definition of what the=C2=A0Base MPLS Imposition MSD is, but that defini= tion may not match what is discussed here.=C2=A0 The intent may be the same= , but the text is different, and given the extensive discussion prior to th= e publication of rfc8491, I want to make sure that we are in fact talking a= bout the same thing: "label stack depth push limit=E2=80=9D doesn=E2= =80=99t directly map to "the total number of MPLS labels that can be i= mposed, including all service/transport/special labels=E2=80=9D [rfc8491].= =C2=A0 I note that this document specifically mentions just transport label= s.

If the definition of = the=C2=A0BMI-MSD is what is expected in this document, please explicitly sa= y so.=C2=A0 If not, then I think that we would need to define a new MSD-Typ= e for the suggestions above to be applicable.

[Pavan] The =E2=80=9Clabel stack d= epth push limit=E2=80=9D 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 relations= hip to=C2=A0the BMI-MSD is explicitly made.

I see = the text (in parenthesis) that you added in =C2=A75.3: "label stack de= pth push limit (number of MPLS labels that can be imposed)=E2=80=9D, but th= at doesn=E2=80=99t make reference to either the BMI-MSD or rfc8491.=C2=A0 A= lso, the text added is not the complete definition.=C2=A0

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

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

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

>> All this would make rfc8491 a Normative re= ference.

Would it? Please note that the =E2=80=9Ce= xplicit delegation=E2=80=9D can be implemented without needing to implement= any of the standard BMI-MSD learning technologies. The RFC8491 mechanism i= s just one option. As stated earlier, an implementation may choose to emplo= y any of the following mechanisms besides RFC8491 =E2=80=94=C2=A0 OSPF (RFC= 8476), BGP-LS (draft-ietf-idr-bgp-ls-segment-routing-msd), PCEP (draft-ietf= -pce-segment-routing), local config (just set a global limit), netconf/rest= conf/grpc using the data-model specified in draft-ietf-teas-yang-sr-te-topo= .

I would h= ave preferred if a Normative reference was made to BMI-MSD to avoid any con= fusion (vs copying the definition here).=C2=A0 That=E2=80=99s were I think = that rfc8491 would be Normative; not in the mechanism, but in the definitio= n.

In any case, I guess the way you wrote it above is ok as well.=C2= =A0 I=E2=80=99ll clear the DISCUSS when you publish an update.

Thanks= !!

Alvaro.

--00000000000001e87d0580c7f3ee--