Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework
"Zhenlong Cui" <c-sai@bx.jp.nec.com> Thu, 14 November 2013 11:51 UTC
Return-Path: <c-sai@bx.jp.nec.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 7F9A821E80B6 for <mpls@ietfa.amsl.com>; Thu, 14 Nov 2013 03:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Level:
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJfvwQcrJOKY for <mpls@ietfa.amsl.com>; Thu, 14 Nov 2013 03:51:53 -0800 (PST)
Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id AC3F721E8090 for <mpls@ietf.org>; Thu, 14 Nov 2013 03:51:52 -0800 (PST)
Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAEBpoeu018643; Thu, 14 Nov 2013 20:51:50 +0900 (JST)
Received: from mailsv4.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id rAEBpnh22675; Thu, 14 Nov 2013 20:51:49 +0900 (JST)
Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAEBpnL1029230; Thu, 14 Nov 2013 20:51:49 +0900 (JST)
Received: from yonosuke.jp.nec.com ([10.26.220.15] [10.26.220.15]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-28040; Thu, 14 Nov 2013 20:51:14 +0900
Received: from VPCS7083 ([10.38.126.83] [10.38.126.83]) by mail.jp.nec.com with ESMTP; Thu, 14 Nov 2013 20:51:13 +0900
From: Zhenlong Cui <c-sai@bx.jp.nec.com>
To: 'Lou Berger' <lberger@labn.net>, mpls@ietf.org
References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net>
In-Reply-To: <527D51B6.1060106@labn.net>
Date: Thu, 14 Nov 2013 20:51:13 +0900
Message-ID: <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_097C_01CEE17B.4143EA40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKjcmuX2mpL/9O/4vEBAfSw2EoiNQI1xyzEAR+Coq0BaI8zcAJ+CQwLArAVKgmYLBl8sA==
Content-Language: ja
Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 14 Nov 2013 11:51:57 -0000
Lou, I agree your opinion. I looked through the draft, there are few comments as an attached file. I hope you will find it informative before you post a new version of the draft. Best reagrds, zhenlong > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Saturday, November 09, 2013 6:04 AM > To: Zhenlong Cui; mpls@ietf.org > Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework > > > Zhenlong, > > I understand you have an additional concern regarding supporting a MIP and MEP in a node that is both a branch and leaf > node. I think this is supported, where MIPs are associated with the P2MP branch data plane function and MEPs are associated > with the leaf data plane function. > This holds for both for both per-node and per-interface MIPs. I certainly agree that it is reasonable for there to be > a more in depth discussion on this topic, and suggest that such a discussion be added to draft-hmk-mpls-tp-p2mp-oam-framework. > > If you'd like, we can something like the following to our draft: > > It is worth noting that a MIP and MEP may be instantiated on a node > when it is both a branch and leaf node. > > Please let us know if you still have concerns on our document. > > Thank you, > Lou > > On 11/5/2013 11:05 AM, Lou Berger wrote: > > Zhenlong, > > > > Perhaps the issue is in the slightly different language used in the > > draft versus the section 3.7 of rfc6371. RFC6371 says: > > > > o To send an OAM packet to a single MIP, ... The OAM packet must > > contain sufficient information to identify the target MIP and > > therefore is processed only by the target MIP and can be silently > > discarded by the others. > > > > To better align with this text, the draft should be revised to replace > > "addressing information" with "additional information" > > > > Will this address your comment? If not, do you have some text/changes > > in mind that would? > > > > Much thanks, > > Lou > > > > On 11/4/2013 12:56 AM, Zhenlong Cui wrote: > >> Hi Lou, > >> > >> Thank you for your reply. > >> > >> I was relieved to know that you already considered the case that both MEP and MIP functionality are configured on > a transit node. > >> > >> However, I think that this draft need further explanation for the OAM behavior on transit nodes. > >> > >> The P2MP OAM behaviors are described in section 4. > >> All the traffic sent over a P2MP transport path, including OAM > >> packets generated by a MEP, is sent (multicast) from the root to all > >> the leaves, thus every OAM packet is sent to all leaves, and thus can > >> impact all the MEs in a P2MP MEG. If an OAM packet is to be > >> processed by only a specific leaf, it requires information to > >> indicate to all other leaves that the packet must be discarded. To > >> address a packet to an intermediate node in the tree, TTL based > >> addressing is used to set the radius and addressing information in > >> the OAM payload is used to identify the specific destination node. > >> > >> > >> My comments: > >> > >> 1)As defined in RFC 6426, the IF_Num is used to identify the specific destination node and interface. > >> The case of per-interface should also be described, if you like to mention about the per-node case in this draft. > >> > >> 2)May need further explanation for the OAM behavior in case that both MEP and MIP functionality are configured on > a transit node. > >> e.g.) > >> When a transit node receive a OAM packet, the transit node has to determine whether the OAM packets should be processed > by a MIP functionality, before it identifies the addressing information. > >> Because MIP functionality is usually implemented by software. This behavior will be help to block the DDOS attack. > >> > >> > >> Best reagrds, > >> zhenlong > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: Monday, November 04, 2013 1:17 PM > >>> To: Zhenlong Cui; mpls@ietf.org > >>> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >>> Subject: Re: [mpls] working group last call on > >>> draft-ietf-mpls-tp-p2mp-framework > >>> > >>> Zhenlong, > >>> Thank you for the comments. Please see below for responses in-line. > >>> > >>> On 10/22/2013 2:18 AM, Zhenlong Cui wrote: > >>>> Dear authors, > >>>> > >>>> I have a comment/question on this draft. > >>>> > >>>> As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. > >>>> In this case, the drop-and-continue node will become an intermediate point. > >>> > >>> Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. > >>> > >>>> So, can we configure a MEP on an intermediate node(= drop-and-continue node)? > >>> > >>> I think this is a matter of semantics. By definition a MEP is only on egress (leaf) nodes and a MIP only on transit > nodes. > >>> Assuming you are asking about the case stated in the previous point, > >>> that a node is both egress and transit, then I think it could have both MEP and MIP functionality separately instantiated. > Section 3.7 already covers P2MP MIPs and MEPs. > >>> > >>>> As described in section 3.3 of RFC 6371, a MEP terminates all the > >>>> OAM packets it receives from the MEG, may discards silently if > >>>> addressing information in the OAM payload is different with > >>> termination node. > >>>> It means that the intermediate node must NOT be configured as a MEP > >>>> when per-node OAM configuration is used, because downstream nodes can't receive the OAM packets from root node. > >>> > >>> Why do you say this? If a node is both transit and egress, it will > >>> replicate OAM packets (just like the data) when performing its transit role before then terminating the data/OAM packets > as part of its egress role. > >>> > >>>> > >>>> On the other hand, if the intermediate node can't be configured as > >>>> a MEP, the path protection may not be able to work at this point. I think this is a serious problem. > >>>> > >>> > >>> Perhaps I'm missing something, but I simply don't see an issue here > >>> that isn't already addressed in RFC6371 (and 4875.) I guess 6371 > >>> could have shown this case as an example, or provided a related detailed walk through, but either way I don't see > any "serious problem" here. > >>> > >>> Perhaps the best way to proceed on this is to propose text to the > >>> already referenced "additional detail" draft draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? > >>> > >>> Thanks, > >>> Lou > >>> > >>>> Best regards, > >>>> zhenlong > >>>> > >>>>> -----Original Message----- > >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>>>> Behalf Of Loa Andersson > >>>>> Sent: Friday, October 18, 2013 1:29 PM > >>>>> To: mpls@ietf.org > >>>>> Cc: mpls-chairs@tools.ietf.org; > >>>>> draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >>>>> Subject: [mpls] working group last call on > >>>>> draft-ietf-mpls-tp-p2mp-framework > >>>>> > >>>>> Working Group, > >>>>> > >>>>> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. > >>>>> > >>>>> Please send your comment to working group mailing lists (mpls@ietf.org). > >>>>> > >>>>> We did an IPR poll on this document prior to starting the wglc. > >>>>> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. > >>>>> > >>>>> There are no IPRs disclosed against this document. > >>>>> > >>>>> The working group last call will end Friday November 1, 2913. > >>>>> > >>>>> /Loa > >>>>> mpls wg co-chair > >>>>> -- > >>>>> > >>>>> > >>>>> Loa Andersson email: loa@mail01.huawei.com > >>>>> Senior MPLS Expert loa@pi.nu > >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> > >> > >> > >> > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > >
- [mpls] working group last call on draft-ietf-mpls… Loa Andersson
- Re: [mpls] working group last call on draft-ietf-… Zhenlong Cui
- [mpls] Closed : working group last call on draft-… Loa Andersson
- Re: [mpls] working group last call on draft-ietf-… Lou Berger
- Re: [mpls] working group last call on draft-ietf-… Zhenlong Cui
- Re: [mpls] working group last call on draft-ietf-… Lou Berger
- Re: [mpls] working group last call on draft-ietf-… Lou Berger
- Re: [mpls] working group last call on draft-ietf-… Zhenlong Cui
- Re: [mpls] working group last call on draft-ietf-… Lou Berger
- Re: [mpls] working group last call on draft-ietf-… Zhenlong Cui
- Re: [mpls] working group last call on draft-ietf-… Lou Berger
- Re: [mpls] working group last call on draft-ietf-… Gregory Mirsky
- Re: [mpls] working group last call on draft-ietf-… Gregory Mirsky
- Re: [mpls] working group last call on draft-ietf-… Lou Berger
- Re: [mpls] working group last call on draft-ietf-… Lou Berger
- Re: [mpls] working group last call on draft-ietf-… Gregory Mirsky
- Re: [mpls] working group last call on draft-ietf-… Zhenlong Cui