Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework

"Zhenlong Cui" <c-sai@bx.jp.nec.com> Fri, 15 November 2013 02:42 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 9D02E11E8176 for <mpls@ietfa.amsl.com>; Thu, 14 Nov 2013 18:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level:
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[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 Sc4ISnJnQGv6 for <mpls@ietfa.amsl.com>; Thu, 14 Nov 2013 18:42:31 -0800 (PST)
Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 368A711E8170 for <mpls@ietf.org>; Thu, 14 Nov 2013 18:42:28 -0800 (PST)
Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAF2gQPi021042; Fri, 15 Nov 2013 11:42:26 +0900 (JST)
Received: from mailsv.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 rAF2gQh13019; Fri, 15 Nov 2013 11:42:26 +0900 (JST)
Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAF2gPTW001434; Fri, 15 Nov 2013 11:42:25 +0900 (JST)
Received: from kaishu.jp.nec.com ([10.26.220.5] [10.26.220.5]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-645312; Fri, 15 Nov 2013 11:41:50 +0900
Received: from VPCS7083 ([10.38.126.83] [10.38.126.83]) by mail.jp.nec.com with ESMTP; Fri, 15 Nov 2013 11:41:50 +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> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net>
In-Reply-To: <5284F610.6050807@labn.net>
Date: Fri, 15 Nov 2013 11:41:49 +0900
Message-ID: <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKjcmuX2mpL/9O/4vEBAfSw2EoiNQI1xyzEAR+Coq0BaI8zcAJ+CQwLArAVKgkDj+8ESQHLim8TmAI2cfA=
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: Fri, 15 Nov 2013 02:42:35 -0000

Loa,

Thank you for your reply. Please see below for responses in-line.


> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, November 15, 2013 1:11 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,
> 
> Thank you for the comments.
> 
> Here are your comments, as extracted from word, and my responses.
> (Clearly the page numbers are wrong.)
> 
> > Page 120: Deleted zc 11/14/2013 6:26:00 PM , [RFC5860], and [RFC5951]
> > Page 121: Comment [zc1] zc 11/14/2013 8:02:00 PM
> > RFC5860 and RFC5951 have not been summarized in this section.
> 
> You are correct. To fix, I propose to add the following:
> 
>    From [RFC5860]:
> 
>    o  The protocol solution(s) developed to perform the following OAM
>       functions must also apply to point-to-point associated
>       bidirectional LSPs, point-to-point unidirectional LSPs, and point-
>       to-multipoint LSPs:
> 
>       *  Continuity Check
> 
>       *  Connectivity Verification, proactive
> 
>       *  Lock Instruct
> 
>       *  Lock Reporting
> 
>       *  Alarm Reporting
> 
>       *  Client Failure Indication
> 
>       *  Packet Loss Measurement
> 
>       *  Packet Delay Measurement
> 
>    o  The protocol solution(s) developed to perform the following OAM
>       functions may also apply to point-to-point associated
>       bidirectional LSPs, point-to-point unidirectional LSPs, and point-
>       to-multipoint LSPs:
> 
>       *  Connectivity Verification, on-demand
> 
>       *  Route Tracing
> 
>       *  Diagnostic Tests
> 
>       *  Remote Defect Indication
> 
>    From [RFC5951]:
> 
>    o  For unidirectional (P2P and point-to-multipoint (P2MP))
>       connection, proactive measurement of packet loss and loss ratio is
>       required.
> 
>    o  For a unidirectional (P2P and P2MP) connection, on-demand
>       measurement of delay measurement is required.

Agree.

> 
> 
> > Page 197: Inserted zc 11/14/2013 6:34:00 PM The requirements for
> > MPLS-TP OAM are specified in [RFC5860].
> Sure.
> 
> > Page 197: Comment [zc2] zc 11/14/2013 8:34:00 PM Moved from section 2.
> > If necessary, addition a summary of OAM
> requirements as other
> > section is much better.
> See response above.

Agree.

> 
> > Page 199: Comment [zc3] zc 11/14/2013 8:02:00 PM Missing link
> > [Multiple places]
> Links come from the html tools page, not the source XML.

Ok, I understand.

> 
> > Page 203: Inserted zc 11/14/2013 6:29:00 PM OAM Packets is sent to all
> > leaves and processed by Page 203: Deleted zc 11/14/2013 6:29:00 PM
> > every OAM packet Page 203: Comment [zc4] zc 11/14/2013 8:42:00 PM I
> > think that's not necessarily true. Because some on-demand OAM
> packets may be dropped
> > by intermediate node. That mean not every OAM packet is sent to leaves.
> > Page 203: Deleted zc 11/14/2013 6:29:00 PM is sent to all leaves, and
> > thus can impact
> 
> So your point is that an intermediate node may drop an OAM packet?  If so, yes, this is true for P2P case too.
> 
> How about:
> DROP (redundant statement):
>   thus every OAM packet is sent to all leaves, s/can impact/may be processed by

My primary concern:
 I think there is a discrepancy between "every OAM packet is sent to all leaves" and "To address a packet to an intermediate node in the tree, TTL based ..."

My understanding:
 "every OAM packet is sent to all leaves" is equal to "no OAM packet is sent to branches".
 On the other hand, "To address a packet to an intermediate node in the tree, TTL based ...", it seems meaning that "the root may send OAM packet to branches".

 Is my understanding correct?


> 
> > Page 208: Deleted zc 11/14/2013 6:42:00 PM addressing Page 208:
> > Comment [zc5] zc 11/14/2013 8:43:00 PM We have agreed on this change.
> > Page 208: Inserted zc 11/14/2013 6:42:00 PM additional
> Agreed.
> 
> > Page 209: Deleted zc 11/14/2013 7:29:00 PM node Page 209: Comment
> > [zc6] zc 11/14/2013 8:02:00 PM In the per-interface case, additional
> > information should be used to
> identify the specific
> > interface of the destination node. Considering the per-node and
> per-interface case, I think
> > delete "node" is much better.
> Sure.
> 
> > Page 209: Inserted zc 11/14/2013 7:55:00 PM It is worth noting that a
> > MIP and MEP may be instantiated on a node
> when it
> > is both a branch and leaf node.
> Slightly rephrased:
>       It is worth
>       noting that a MIP and MEP may be instantiated on a single node
>       when it is both a branch and leaf node.<

No problem.

> 
> > Page 217: Comment [zc8] zc 11/14/2013 8:02:00 PM MPLS-TP has many OAM
> > functions.
> Agreed.
> 
> > I am not sure why did you mention the PM function only in this
> > section.
> 
> I suspect that this text was added to align with the two requirements from RFC5951.
> 
> I have no problem just dropping this sentence and leaving the more detailed discussion of requirements to
> hmk-mpls-tp-p2mp-oam-framework

I agree with your opinion that dropping this sentence and leaving the more detailed discussion of requirements to hmk-mpls-tp-p2mp-oam-framework.


> 
> > Page 305: Comment [zc10] zc 11/14/2013 8:02:00 PM Branch include
> > intermediate node and leaf node. Are you sure you want
> to say that all of the
> > intermediate node needs to identify fault condition?
> > Page 305: Deleted zc 11/14/2013 6:33:00 PM branches Page 305: Inserted
> > zc 11/14/2013 6:33:00 PM leaves
> 
> I don't think any specific solution guidance was intended.  How about:
> OLD
>       For 1:1, the source/root MPLS-TP node needs to identify the
>       existence of a fault condition on any of the branches of the
>       network.
> NEW
>       For 1:1, the source/root MPLS-TP node needs to identify the
>       existence of a fault condition impacting delivery to any of
>       the leaves.

Agree.

> 
> > Page 307: Deleted zc 11/14/2013 7:24:00 PM and Page 307: Inserted zc
> > 11/14/2013 7:24:00 PM or Page 307: Comment [zc11] zc 11/14/2013
> > 8:02:00 PM It is correct?
> How about:
> s/and/and, perhaps,

s/and/and? Is this a mistake?
My propose is s/and/or.


Best regards,
zhenlong

> 
> I think that's it.
> 
> Thank you again for your comments.
> 
> Lou
> 
> On 11/14/2013 6:51 AM, Zhenlong Cui wrote:
> > 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
> >>>
> >>>
> >>>
> >>>