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

[Lou Berger <[e-mail]>]

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:[e-mail]]
>> Sent: Saturday, November 09, 2013 6:04 AM
>> To: Zhenlong Cui; [e-mail]
>> Cc: [e-mail]
>> 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:[e-mail]]
>>>>> Sent: Monday, November 04, 2013 1:17 PM
>>>>> To: Zhenlong Cui; [e-mail]
>>>>> Cc: [e-mail]
>>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>>>>> Behalf Of Loa Andersson
>>>>>>> Sent: Friday, October 18, 2013 1:29 PM
>>>>>>> To: [e-mail]
>>>>>>> Cc: [e-mail];
>>>>>>> [e-mail]
>>>>>>> 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 ([e-mail]).
>>>>>>>
>>>>>>> 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: [e-mail]
>>>>>>> Senior MPLS Expert                          [e-mail]
>>>>>>> Huawei Technologies (consultant)     phone: [phone]
>>>>>>> _______________________________________________
>>>>>>> mpls mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>>
>>>