Re: [mpls] 答复: [CCAMP] Question regarding RFC 7260

"Adrian Farrel" <> Thu, 23 February 2017 10:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40E3E1296AB; Thu, 23 Feb 2017 02:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w-dwvQDi5s79; Thu, 23 Feb 2017 02:39:55 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8F9B1293EC; Thu, 23 Feb 2017 02:39:54 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id v1NAdigu026286; Thu, 23 Feb 2017 10:39:45 GMT
Received: from 950129200 ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v1NAde8D026164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 10:39:42 GMT
From: "Adrian Farrel" <>
To: "'Fatai Zhang'" <>, "'Naveen T'" <>, <>, "'Mpls'" <>
References: <> <> <>
In-Reply-To: <>
Date: Thu, 23 Feb 2017 10:39:39 -0000
Message-ID: <067501d28dc1$25600520$70200f60$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0676_01D28DC1.256CD660"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL990RH2ugbfaOlzCXRV8GfVC0otwJW6xTYAtITMuae9krAoA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--17.304-10.0-31-10
X-imss-scan-details: No--17.304-10.0-31-10
X-TMASE-MatchedRID: JorHcieTUslbJCKOm3VRCQqiCYa6w8tvVhbDEH23DRMTBiHOxTa+oMG1 y5Mr1FI7lHVBLjBDrjn7PZziWKg+SED6nbwbhGT/+hwb6PyejK1xkDaYjAh4s5l1NkUS1ZjtXAm LLEWkAyi1GEy290CHW29BwOBTwhNHTnFsT79fjaAS6DTmG2utgD+zj3UoOhXMqIdIJyMZyDHF9R lT/nv4RQeLjYCwRCMCZlRzaO1xpJ0RNp7xD+4vUbFbhhcWxNQO+kUWlbuaEXoIEfymFOt6UuLMO JyauTQrFTpE2FWj6UR/n3z4qeww6KKaxHqGRwkC7jMwsd7VA9vzPvRcNNSOxssNbe7UzKvVcEub fZJ7ptX0aUnP7vi4bO9VsdrlGzy3Q6/DFZugyt0wODfUl7mJKf4ZAUsty2ENqv6+7o00zYeLFgn z+hpr+XW0oJLOugKBj1RGQOB2Vvn9GaYSzB/sh6Jd7mc2dRi3oEozraubH2nx6gF+AN4QjuBe5Q RmIfivPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBcqoeXFMnt4lSJunynLhcivKEdCt wyfJsLWV8MKb34RlRZU/yoIC8o9KBrXVItRacs2O8d0ViWprFQ+CF9xoc5LnE2RogVHfH2sEFKe f8ZUxpcqz3g0A4fyupDIC9422DrTMQ/93vE8XUbaqUVvLFsiK3jMD4yr7CrRM7el56AWz57jobR LBotGT+Zs2lM+sEAQ9/tMNQ4aitAAxzBVg/FDnp9KgXcu34zy67HGlbS8BBjoZ88Td/8U01ykkc 2tV9zyUQNiagGSs9sfxZpQv2qM5VDS2tfzNYKbKItl61J/yZUdXE/WGn0FVoTa5lFknUGHHQtvy gWztDwM/9PPoyyDsVLHNbpaYroHSsTCB737Jy9AdBvsBxTLcQRIvzHqbng=
Archived-At: <>
Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBbQ0NBTVBdIFF1ZXN0aW9uIHJlZ2FyZGluZyBS?= =?utf-8?q?FC_7260?=
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 10:39:57 -0000

Fatai is right, I think.
If you want to operate "static" MPLS LSPs without using a control plane, then it would (IMO) be peculiar to suddenly want to use a control plane to configure and manage OAM on that LSP.
Why would you not use the same static provisioning tools?
Of course, there is also RFC 7212 available to you.
From: mpls [] On Behalf Of Fatai Zhang
Sent: 23 February 2017 03:30
To: Naveen T;; Mpls
Subject: [mpls] 答复: [CCAMP] Question regarding RFC 7260
Hi Naveen,
Per RFC 7487,  I think there should be GMPLS control plane for OAM configuration purpose. 
发件人: CCAMP [] 代表 Naveen T
发送时间: 2017年2月22日 21:50
收件人:; Mpls
主题: [CCAMP] Question regarding RFC 7260
Dear Authors, et al.,
RFC 7260 <>  describes the procedures for OAM configuration and control via RSVP-TE. RFC 7467 <>  further extends this to provide procedures to configure pro-active OAMs like BFD, FMS etc. 
I have a query regarding the usage of RSVP-TE to carry the OAM configurations from the MPLS-TP tunnel ingress to the tunnel egress.
Considering that the MPLS-TP bi-directional LSP has been established statically and the requirement is to only signal the OAM entities, I have the following assumptions:
1.  An IGP path must be established between the MPLS-TP tunnel's ingress and egress LERs.
2.  The MPLS-TP node_id of and LER/LSR, defined here <> , will also be configured as that LER's/LSR's loopback interface's address.
3.  The IGP will ensure that each LER/LSR learns about all the LSRs/LERs along the MPLS-TP transport path.
4.  RSVP-TE will use this IGP path to send/receive the PATH/RESV messages.
Are these assumptions correct?
Or, should there be a GMPLS control-plane adjacency between LERs/LSRs along the MPLS-TP path with the TE links on these nodes acting as the MPLS-TP NNI interfaces?
Thanks and Regards,
Naveen T