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