Re: [mpls] status and paln for draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp

["Aissaoui, Mustapha (Mustapha)" <[e-mail]>]

Dear all,
I read this draft and I have the following comments.

1. General comment:
While I understand the need to work around a node which does not support re-merge of S2L paths in the data plane (section 3), I am not able to comprehend the need to avoid a node which supports it (section 4). 
In a network where the ingress LER, or a border LSR, does not have visibility of the entire network topology, a LSR node which supports the re-merge in data plane is actually preventing further unnecessary replication of traffic downstream of itself. However, it seems this draft is treating this as a bad thing and is adding complicated procedures to record re-merge points and in trying to avoid them may cause more duplication of packets over the network. This is because if the ingress LER, or border LSR, decided to branch out two sets of S2L paths by signaling them out off different border LSR nodes and then these two sets intersected again in a downstream domain, rerouting them by excluding the re-merge node will only force one of the 2 S2L sets to use disjoint paths and may cause duplication deeper into the network.

Thus, I suggest that this draft focuses on describing resignaling procedures at ingress LER and border LSR nodes in the case of receiving a PathErr with error code "Routing Problem" and error value "ERO resulted in re-merge". This is because I can see that given the lack of topology knowledge at the ingress LER and border LSR, there is a possibility of re-merge in downstream domain on a node which does not support data plane merging. Since this may not be a correctable condition and can prevent some leaves from joining the tree, re-routing a set of S2L paths by avoiding the node which does not suppot re-merge in the data plane, and thus causing potentially more duplication, might be an acceptable trade-off.

This means keep section 3 but remove section 4. I am thus focusing my comments on Section 3.

2.  Section 3 - Control Plane Solution For Re-merge Handling
"
It is RECOMMENDED that boundary re-routing is requested for P2MP LSPs
   traversing multiple domains. This is because border nodes that are
   expanding loose hops are typically best placed to correct any re-
   merge errors that occur within their domain, not the ingress node.
"
I am having trouble understanding why a border node is best placed for correcting a re-merge situation in its downstream domain. Unless the border node itself created the re-merge situation when expanding the EROs for 2 sets of S2Ls and in which case it can be corrected at the next re-optimization of those S2Ls, the most likely reason for re-merge is that the ingress LER, due to limited topology view, signaled the two sets over two different border LSRs and then they intersected in the second domain. But then, each border node is only handling one set of S2Ls. 
In the latter case, I can see that the border node which received the PathErr messages may want to avoid the re-merge node by rerouting around it and thus achieving a higher S2L establishment rate at the expense of more traffic duplication in the network.

3. Section 3.1. - Single Border Node For All S2Ls
"
   It is RECOMMENDED that the ingress node of a P2MP LSP selects the
   same ingress border node in the loose hop ERO for all sibling S2L
   sub-LSPs that transit through a given domain. The reason is that it
   will increase the possibility of re-merge downstream if two or more
   border nodes have roles simultaneously to expand loose EROs. An
   ingress border node that performs the loose ERO expansion for
   individual sub-LSP(s) has the necessary state information for the
   destinations transiting through its domain to ensure computed P2MP
   tree is re-merge free.
"
Without full topology knowledge, this is just another arbitrary decision like the one which caused the re-merge to occur in the first place. 

4. Section 3.2 - Crankback and PathErr Signaling Procedure
Overall I think this section should explain what additional information is needed on top of the PathErr message provided in RFC 4875 such that the cranckback information is meaningful. For example, you may want to report the reporting node-id, which can be the border node which attempted to avoid the re-merge node but was unsuccessful. 

--------------------------------------------------------------------------------------------------------------------

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Loa Andersson
Sent: Saturday, May 25, 2013 1:42 PM
To: [e-mail]; Adrian Farrel; [e-mail]; VIGOUREUX, MARTIN (MARTIN)
Subject: [mpls] status and paln for draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp

Working Group,

On 2013-05-20 we requested publication of draft-ietf-mpls-inter-domain- p2mp-rsvp-te-lsp as an RFC on the Standards Draft.

After a timely and detailed AD review the document has been "returned to the working group for more work".

The AD review comments has been has been sent to the working group mailing list and to the authors. The comments are comprehensive, nevertheless the author should proceed as usual:

- Create a list of the comments and for each comment explain how each
   comment has been addressed and verify that Adrian is comfortable
   about how the comments have been address. This process should to
   the extent possible take place on the mailing list.

After further discussion with Adrian we have agreed that I as the document shepherd should organize a review by "P2MP implementers".

- The comments received via this review should be handle the same
   way as the comments from the AD review.

I've a few names that I think fit the "P2MP implementer" profile, and will soon send out mails directly to them.

I'm also looking for more willing reviewers that are willing to undertake this review. If you are interested please send a uni-directional mail to me or to the working group chairs.

/Loa
for the MPLS wg co-chairs
-- 


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