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

Lou Berger <lberger@labn.net> Thu, 14 November 2013 16:11 UTC

Return-Path: <lberger@labn.net>
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 E7BC721E80B2 for <mpls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:11:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.951
X-Spam-Level:
X-Spam-Status: No, score=-101.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 fykz49ejudNT for <mpls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:11:16 -0800 (PST)
Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 0796721E8056 for <mpls@ietf.org>; Thu, 14 Nov 2013 08:11:15 -0800 (PST)
Received: (qmail 18551 invoked by uid 0); 14 Nov 2013 16:10:50 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 14 Nov 2013 16:10:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PMT17pkq1M3wPljHoV/h/59JxyPA+MwMQx6cazm8vfY=; b=HBRO4GYdVlbgXzrfisQUWCWpnKwtLjMCd4XZmqgvxcNURswA1I4KWkjjPb4vxo5p6uu+WkOq1f1/ONSWrHR5WSDn4KcojVCZEDja5Gcjous6TmdpZpP/SwbpBQ3x3Ehl;
Received: from box313.bluehost.com ([69.89.31.113]:45893 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1VgzVK-00036e-9D; Thu, 14 Nov 2013 09:10:50 -0700
Message-ID: <5284F610.6050807@labn.net>
Date: Thu, 14 Nov 2013 11:10:56 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Zhenlong Cui <c-sai@bx.jp.nec.com>, 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>
In-Reply-To: <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
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 16:11:23 -0000

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.


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

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

> 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

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

> 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

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

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

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