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

From: Loa Andersson <[email-masked]>
Date: Sat, 02 Nov 2013 14:54:50 +0800

Working Group,

this working group last call is closed. There have been comment.
Could the authors please address the comments and post a new version
as necessary.

/Loa
for the mpls wg co-chairs

On 2013-10-18 12:28, Loa Andersson wrote:
> 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 ([email-masked]).
>
> 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: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Lou Berger <[email-masked]>
Date: Sun, 03 Nov 2013 20:17:17 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
>> Sent: Friday, October 18, 2013 1:29 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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.
>>
>> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document.
>>
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> 
> 
>

---

From: "Zhenlong Cui" <[email-masked]>
Date: Mon, 4 Nov 2013 17:56:55 +0900

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

> From: Lou Berger [mailto:[email-masked]]
> Sent: Monday, November 04, 2013 1:17 PM
> To: Zhenlong Cui; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework
> 
> Zhenlong,
> Agreed.  This node will be both a transit node and an egress/leaf.  This case is covered in RFC4875.
> 
> 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
> >> Cc: [email-masked];
> >> [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Nov 2013 11:05:52 -0800

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 08 Nov 2013 13:03:50 -0800

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

---

From: "Zhenlong Cui" <[email-masked]>
Date: Thu, 14 Nov 2013 20:51:13 +0900

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

> Sent: Saturday, November 09, 2013 6:04 AM
> 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.
> 
> > Will this address your comment? If not, do you have some text/changes
> > in mind that would?
> >
> > Much thanks,
> > Lou
> >
> >>    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.
> >>> 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.
> >>> 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.
> >>>
> >>> already referenced "additional detail" draft draft-hmk-mpls-tp-p2mp-oam-framework.  Does this work for you?
> >>>
> >>> Thanks,
> >>> Lou
> >>>
> >>>> Best regards,
> >>>> zhenlong
> >>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Nov 2013 11:10:56 -0500

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

---

From: "Zhenlong Cui" <[email-masked]>
Date: Fri, 15 Nov 2013 11:41:49 +0900

Loa,

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

> Sent: Friday, November 15, 2013 1:11 AM
> > Page 120: Deleted zc 11/14/2013 6:26:00 PM , [RFC5860], and [RFC5951]

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]

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

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
> > Page 305: Deleted zc 11/14/2013 6:33:00 PM branches Page 305: Inserted
> > zc 11/14/2013 6:33:00 PM 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 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.
> >> 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.
> >>
> >>> 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
> >>>
> >>>>  I was relieved to know that you already considered the case that
> >>>> both MEP and MIP functionality are configured on
> >> a transit node.
> >>>>
> >>>>  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
> >>>>> 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.
> >>>>>> 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
> >>>>>> 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

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Nov 2013 10:37:06 -0500

Zhenlong,

See below.  I've cut topics with resolutions/agreements.

>> (Clearly the page numbers are wrong.)

[...]

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

Okay, I understand your point.  I think your reading / the text does not
match our intent.  (Which is certainly to allow for both MIP and MEP
processing.)

How about:
s/to all leaves/towards all leaves

Which will result in:
     All the traffic sent over a P2MP transport path, including
     OAM packets generated by a MEP, is sent (multicast) from the
     root towards all the leaves, and thus may be processed by all
     the MEs in a P2MP MEG.

[...]

> s/and/and? Is this a mistake?

Sorry for not being clear.  I was proposing the following final text:
    Fault notification happens from the node
    identifying the fault to the root node and, perhaps, from the
    leaves to the root via an out of band path.

Now rereading the sentence I think I'd prefer just dropping the
reference to leaves as it really doesn't add anything.  How about:
      Fault notification happens from the node
      identifying the fault to the root node via an out of band path.

And also dropping "In either case" immediately following to align the
next sentence.

That's it.  Thank you again for your comments.

Lou

> zhenlong
[...]

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 15 Nov 2013 21:25:17 +0000

Hi Lou,
I've got confused with use of ME in 

Which will result in:

Maintenance Entity (ME) is association of two or more MEPs. Perhaps it should be "by all Maintenance Points (MPs) in a P2MP MEG" since in MPLS-TP MEG consists of only one ME and thus both terms can be used interchangeably.

	Regards,
		Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 15 Nov 2013 21:50:37 +0000

Hi Lou, et. al,
though it might be not canonical but often "node that is both leaf and branch node" referred as "bud node".

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Friday, November 15, 2013 7:37 AM
To: Zhenlong Cui; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework

Zhenlong,

[...]

>>
>>> 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 
>>> Page 203: Deleted zc 11/14/2013 6:29:00 PM is sent to all leaves, 
>>> and thus can impact
>>

Okay, I understand your point.  I think your reading / the text does not match our intent.  (Which is certainly to allow for both MIP and MEP
processing.)

How about:

Which will result in:

[...]

Now rereading the sentence I think I'd prefer just dropping the reference to leaves as it really doesn't add anything.  How about:
      Fault notification happens from the node
      identifying the fault to the root node via an out of band path.

And also dropping "In either case" immediately following to align the next sentence.

Lou

[...]

---

From: Lou Berger <[email-masked]>
Date: Sun, 17 Nov 2013 09:50:25 -0500

I always found this term a bit counterintuitive so am happy that it has 
received limited use....

Lou

On November 15, 2013 4:50:37 PM Gregory Mirsky 
<[email-masked]> wrote:
> 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
> >>   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:
> >  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".
> Now rereading the sentence I think I'd prefer just dropping the reference 
> to leaves as it really doesn't add anything.  How about:

---

From: Lou Berger <[email-masked]>
Date: Sun, 17 Nov 2013 09:55:23 -0500

Greg,

Thanks for the comment.  See below.

On November 15, 2013 4:25:17 PM Gregory Mirsky 
<[email-masked]> wrote:
> Maintenance Entity (ME) is association of two or more MEPs. Perhaps it 
> should be "by all Maintenance Points (MPs) in a P2MP MEG" since in MPLS-TP 
> MEG consists of only one ME and thus both terms can be used interchangeably.
>

How about being completely explicit:
    ...by all MIPs and MEPs associated with a P2MP MEG".

Lou

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 17 Nov 2013 15:41:43 +0000

Hi Lou,
yes, being explicit is the clearest way to express idea.

	Regards,
		Greg

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Sunday, November 17, 2013 6:55 AM
To: Gregory Mirsky; Zhenlong Cui; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework

Greg,

On November 15, 2013 4:25:17 PM Gregory Mirsky <[email-masked]> wrote:
> should be "by all Maintenance Points (MPs) in a P2MP MEG" since in 
> MPLS-TP MEG consists of only one ME and thus both terms can be used interchangeably.
>

Lou

---

From: "Zhenlong Cui" <[email-masked]>
Date: Mon, 18 Nov 2013 09:43:58 +0900

Lou,

Thank you for your reply, this resolves all my comments.

Best regards,
zhenlong

> Sent: Sunday, November 17, 2013 11:50 PM
> I always found this term a bit counterintuitive so am happy that it has received limited use....
> 
> Lou
> 
> 
> On November 15, 2013 4:50:37 PM Gregory Mirsky <[email-masked]> wrote:
> > Hi Lou, et. al,
> > >>> all
> > >>   thus every OAM packet is sent to all leaves, s/can impact/may be
> > >> >>
> > processed by
> > > My primary concern:
> > > 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".
> > tree, TTL based ...", it seems meaning that "the root may send OAM
> > packet to branches".
> > Okay, I understand your point.  I think your reading / the text does
> > not match our intent.  (Which is certainly to allow for both MIP and
> > MEP
> > processing.)
> >
> > How about: