Re: [mpls] draft-sitaraman-mpls-rsvp-shared-labels - FEC validation

Vishnu Pavan Beeram <> Wed, 23 August 2017 06:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3CF21321ED; Tue, 22 Aug 2017 23:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8oHPJApdRpIX; Tue, 22 Aug 2017 23:18:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3200132334; Tue, 22 Aug 2017 23:18:57 -0700 (PDT)
Received: by with SMTP id l132so2283079vke.5; Tue, 22 Aug 2017 23:18:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wxBEC/w7fWEYQ+YExtSLgGgBEEEupGj5DGtdY7g2oMA=; b=TP87sWRGGiKkrIyYyUpgteUBXBhprq+L1BMPwND0vde/YwDI8HpVtWDn+hzuLA7Wjm TKgzfjpHXm4QrDOAQoWkZmoKddadReuahQ6eKOutG/pdn2mMn8ehzzkqbeako41yg2I6 2iCybIgBSQAmJFSnJQhvwH78/Pp7mFFEDERunHj2saFqRQAUWKl07wcsnxW1V5prQeGP /0ZEXzIFP8KRTWVVno6PCGftMR9OKKEvRsef+znaPNQ5QidevIQH1dPgmMtSSt6YRCyF d/9g/h5PMq/vG/4cG16CQ+S6tvD0WOvUta6xK1QrDeVGq14fS9XcVrJsdaCb2/xJ+ljD G3Ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wxBEC/w7fWEYQ+YExtSLgGgBEEEupGj5DGtdY7g2oMA=; b=AkjYXCECwm+U6lBwoExMpSD2maQX5Kuiijo5YAVcDizLIqkpvv/QiW8cKLGlW7O8BE 1j0YPjbE0ac9UHqhK8j3XyStlbrKgN7DtQknJ0WuLisO8LOd88gQST/ZblVo/T/l3q2l eNIgU3rMic1aK8DAFKU2ln7GiA6Ev9Cby9Z9tVIc+F+P1wCkfhu6n2y947VeqmQ7nRsm zmVrOAp+h0NGCDEjxx2b5gw4KpZbXoKIuA0S+vrEzu1VRPlHVW2hdIZkBe25EQG2p8F2 jMp3EzWg1kEd46uf9otj/zPjVIgbM1z6V+4FDeycLOnZAHMSZ3sGJHJUpJpMy3xqJtbi bMlQ==
X-Gm-Message-State: AHYfb5idCcWWGoNIQO5r9yOnpfgL/OztMwuJ9ZQoEDPi1w43ktAWd/qD RqeBm8ho/eDTl8+ragaR1l2EMbontfJgc3A=
X-Received: by with SMTP id p82mr1110291vkd.57.1503469136641; Tue, 22 Aug 2017 23:18:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 22 Aug 2017 23:18:56 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Vishnu Pavan Beeram <>
Date: Wed, 23 Aug 2017 02:18:56 -0400
Message-ID: <>
To: Sam Aldrin <>
Cc:, "" <>
Content-Type: multipart/alternative; boundary="001a114258c6d203e2055765af1d"
Archived-At: <>
Subject: Re: [mpls] draft-sitaraman-mpls-rsvp-shared-labels - FEC validation
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Aug 2017 06:19:00 -0000

WG, Hi!

I just realized that this wasn't responded to on the list. The authors
discussed all of the above questions with Sam in Prague and addressed all
concerns. I'm listing a couple of relevant points here on this thread (just
in case anyone else has similar questions):

(1) There are no changes to “LSP ping echo request/reply" procedures.
(2) The FEC type used is "RSVP IPv4 LSP” (RFC 8029, section 3.2.3) -- note
that this is a single e2e RSVP session.

Please do reach out to the authors if there are any further questions. At
this juncture, we would like to request the WG/chairs to consider this
draft for adoption.

-Pavan (on behalf of the authors)

On Tue, Jul 18, 2017 at 7:02 PM, Sam Aldrin <> wrote:

> Draft authors,
> The OAM section described in the draft is sparse to minimal.
> See the mention of RFC8029, that it could be used without any changes,
> which I entirely disagree.
> Questions:
> 1. How are you encapsulating the LSP Ping Echo request with delegation
> labels and corresponding FEC stack TLV?
> 2. If you are saying that delegation node is going to modify the packet
> and its payload, this is entirely new mechanism and RFC8029 doesn't provide
> mechanics of it. So, add detailed content.
> 3. What is the FEC type being added for delegation label?
> Will comment further, based on the updated content and clarifications.
> -sam
> _______________________________________________
> mpls mailing list