Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06

"lizho.jin" <> Fri, 13 October 2017 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 261DD13243A; Fri, 13 Oct 2017 10:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rW2ikqgUWRcF; Fri, 13 Oct 2017 10:04:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3A7812ECEC; Fri, 13 Oct 2017 10:04:52 -0700 (PDT)
Received: by with SMTP id y7so1651876pgb.7; Fri, 13 Oct 2017 10:04:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding; bh=D05ZO8qM96pVvCy+dMJZkpa48YJGhqdOGXdtnLbuOqA=; b=GilYvBTjAvX8zOiXdPZ7XOBkFdt0Pl6wNKbvVg97orTcKF+ZYa8XxYsNY1KYt30TTR +xCAST5HPBYsEVEXUVCCItNoOVVtguVdKcnGBCsAaQ0MaYceBR8rWCiCGJed2Vh9hR/A reJ4G6kLVCy7nSLOllK4gLl+T514hRm7/JfWDrwVUrmv+aGcTCYFmWvXnMaKdNlabhN1 xg5acUMlDDyzsJYgW8KLN2K6aFZ8lZ3+E98y9WvytgzSqRtNF0WdOxE9rREvBmYyrHe6 LfrJsxUyrMMnRCJNDbs6nsGkxFx78R8il0OBbOilAffqo1CZHgg6kwGUSxQ/IZLc8uIf 4WAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding; bh=D05ZO8qM96pVvCy+dMJZkpa48YJGhqdOGXdtnLbuOqA=; b=tBcYO/tUeGetWPKFMMt7+DIx9mJVCQcFK9s6Vg4/fSc15e32VnlbtEWTdNy6ROrgyU WgcKu+zVEZgUAbS0hrxMLF5hDHiPVsgPC8+5gZQU8/ifs1UgWODU/JSlh2CvhZ4qM63v t1w9qc6vNSJThqUrh7bKGIafJnn3OOjuI5kmdSuJldW594KB2Mu6MOCESI+ojViO6R0B dXv+kr27gz2h6h2A3MJHkE9EHwVFY5Ugm9z6Cr0cLfvhI5iti7OQc8W6l7QaCeturro2 FI6HV4ADkYfb/bbxBCS1h6uHNXj87GHnNTd5UG6Sf3UoRWyoJRh4Xsae2KYcbri+jwqd sDhw==
X-Gm-Message-State: AMCzsaVt8MqjUHujttVN+VM9/2SxzEzProdybRoc8PtCIweXtJkfRts6 I+PBsad4fvuXuelqOCPp5pFGHAg/
X-Google-Smtp-Source: AOwi7QAyeDmrxX10Tuxh4GnIDz3yHnPitNt+4r03nrAX+K/oBQQR+K0PF78CM5h1jN1ChqgTJMB/4w==
X-Received: by with SMTP id a3mr1913049pld.253.1507914292151; Fri, 13 Oct 2017 10:04:52 -0700 (PDT)
Received: from LIZ ([]) by with ESMTPSA id q13sm4094320pfi.166.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 10:04:50 -0700 (PDT)
Date: Sat, 14 Oct 2017 01:03:23 +0800
From: "lizho.jin" <>
To: loa <>, "" <>
Cc: "'Carlos Pignataro (cpignata)'" <>, 'Eric Gray' <>, Ignas Bagdonas <>, mpls-chairs <>, "" <>
Message-ID: <>
In-Reply-To: <>
References: <>
X-Mailer: MailMasterPC/ (Windows 7)
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [mpls] MPLS-RT review draft-shen-mpls-egress-protection-framework-06
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: Fri, 13 Oct 2017 17:04:54 -0000

Hi, Authors
I've been asked to do MPLS-RT review. Overall this kind of egress protection is much easy to deploy, and the mechanism is useful, and technically sound. 
It is ready to consider for WG adoption. And I still have some questions as below:
1. section 1. " example of such extension is [RSVP-EP]."
Typo? It should be RSVP-TE?
2. section 5.9. The protected egress {E, P} which is called a "context ID" is actually an anycast address, right? The terminology of "anycast" used here will be much clear, but it depends on you to choose.
3. section 5.12. It seems bypass tunnel sharing or facility backup scenario missed in this section.
4. section 8. "On PE3, a context label 100 is assigned to the context ID, "
The label 100 should be assigned to the RSVP-TE tunnel with address of context ID, not only to the context ID, since one-to-one backup is used in this example.
5. section 8.1. "R1 computes a bypass path to while avoiding PE2. "
Could you give more explicit way to achieve above without RSVP-TE protocol extensions?

On 9/28/2017 01:14Loa Andersson<> wrote:
Carlos, Eric, Ignas and Lizhong

You have been selected as MPLS-RT reviewers for draft-shen-mpls-egress-

Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own

Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational networks), 
and is the document technically sound?

We are interested in knowing whether the document is ready to be
considered for WG adoption (ie, it doesn't have to be perfect at this
point, but should be a good start). Please remember that it often is
easier to progress the document when it has become a working group
document. All comments in the MPLS-RT review needs to be addressed,
but please think carefully about whether a comment is gating the
adoption or could just as easily be addressed after the adoption.

Reviews should be sent to the document authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
needs to be resolved before adopting it as a working group document, and
what can wait until the document is a working group document and the
working group has the revision control.

Are you able to review this draft by October 13, 2017? Please respond
whether you are available to do the review in a timely fashion.

Thanks, Loa
(as MPLS WG co-chair)

Loa Andersson                        email:
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64