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
> >
> >
> >
> >