IETF Logo Mail Archive

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

Fatai Zhang <zhangfatai@huawei.com> Thu, 23 February 2017 03:30 UTC

Return-Path: <zhangfatai@huawei.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 0F366129F64; Wed, 22 Feb 2017 19:30:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 8GukqqOdYIGQ; Wed, 22 Feb 2017 19:29:59 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DE2129F66; Wed, 22 Feb 2017 19:29:58 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBO11146; Thu, 23 Feb 2017 03:29:54 +0000 (GMT)
Received: from SZXEMA419-HUB.china.huawei.com (10.82.72.37) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 23 Feb 2017 03:29:52 +0000
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.105]) by SZXEMA419-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0235.001; Thu, 23 Feb 2017 11:29:49 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Naveen T <naveen.thanikachalam@yahoo.in>, "ccamp@ietf.org" <ccamp@ietf.org>, Mpls <mpls@ietf.org>
Thread-Topic: [CCAMP] Question regarding RFC 7260
Thread-Index: AQHSjRMzFWxBoQJC8EG6zvjtBuG256F17sQg
Date: Thu, 23 Feb 2017 03:29:49 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF8AAB3C378@SZXEMA504-MBS.china.huawei.com>
References: <1379399279.2996090.1487771407858.ref@mail.yahoo.com> <1379399279.2996090.1487771407858@mail.yahoo.com>
In-Reply-To: <1379399279.2996090.1487771407858@mail.yahoo.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.162.94]
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8AAB3C378SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58AE5733.0226, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: dfd92e0d9ce53d6e2ffa40b5ded7dddc
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ppg9rXveBKyG8i8Xu8xhJZrmCPA>
Subject: [mpls] 答复: [CCAMP] Question regarding RFC 7260
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 23 Feb 2017 03:30:02 -0000

Hi Naveen,

Per RFC 7487,  I think there should be GMPLS control plane for OAM configuration purpose.





Thanks

Fatai

发件人: CCAMP [mailto:ccamp-bounces@ietf.org] 代表 Naveen T
发送时间: 2017年2月22日 21:50
收件人: ccamp@ietf.org; Mpls
主题: [CCAMP] Question regarding RFC 7260

Dear Authors, et al.,

RFC 7260<https://tools.ietf.org/html/rfc7260> describes the procedures for OAM configuration and control via RSVP-TE. RFC 7467<https://tools.ietf.org/html/rfc7487> 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<https://tools.ietf.org/html/rfc6370#section-4>, 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

v2.23.0 | Report a Bug | By Email