Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 3 Oct 2014 23:48:55 +0000

Hi Rakesh, et al,

I see that published WG-01 has all of my comments incorporated. Thanks for considering my comments and notifying me of their completion.

Thanks!

-Nobo

> -----Original Message-----
> From: Rakesh Gandhi (rgandhi)
> Sent: Tuesday, September 30, 2014 9:41 AM
> To: Nobo Akiya (nobo); Loa Andersson; [email-masked]; mpls-
> [email-masked]; VIGOUREUX, MARTIN (MARTIN); draft-tsaad-mpls-
> [email-masked]
> Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-
> p2mp-loose-path-reopt an mpls wg doc
> 
> Thanks Nobo for the review comments. The latest draft addresses the
> review comments.
> 
> Please have a look at this version:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-loose-path-
> reopt-0
> 1.txt
> 
> 
> 
> Thanks,
> Rakesh
> 
> 
> On 2014-08-06 6:46 PM, "Nobo Akiya (nobo)" <[email-masked]> wrote:
> 
> >Hi Loa,
> >
> >I have read this document and support the adoption as a WG document.
> >Not only does this document reduce signaling messages for P2MP-TE
> >re-evaluation and re-optimization, it allow a mid-point LSR to
> >re-evaluate groups of S2L sub-LSPs together without some S2L sub-LSP
> >grouping heuristics, which is quite beneficial.
> >
> >I have few suggestions to authors, but all are not at all stoppers
> >before its WG adoption.
> >
> >
> >1. This is a protocol extension that introduces new objects and
> >procedures, but the document lacks RFC2119 words (i.e. MAY, SHOULD,
> >MUST, etc). It would be highly beneficial to make use of RFC2119 words
> >where necessary (particularly in Sections 3 and 4).
> >
> >
> >2. Abstract, first paragraph, last sentence was slightly difficult to
> >read and had a typo. Suggested new text.
> >
> >[OLD]
> >   Existing mechanisms allow the path re-evaluation and the
> >   signaling of a the notification of preferred path exists for a single
> >   S2L sub-LSP only.
> >
> >[NEW]
> >   Existing mechanisms, a mechanism for a head-end LSR to
> >   trigger a new path re-evaluation and a mechanism for a mid-point LSR
> >   to signal an availability of a preferred path, operate on a single
> >   S2L sub-LSP only.
> >
> >
> >3. Section 3, second paragraph.
> >
> >[snip]
> >   An
> >   ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP
> >   tree to trigger the re-evaluation request(s).
> >[snip]
> >
> >It may be beneficial to clarify the reason behind specifying one or
> >more S2L sub-LSPs, i.e. to specify the sub-groups.
> >
> >
> >4. Section 3, third paragraph.
> >
> >I'd like to propose a bit of rephrase in the last portion of this
> >sentence, for clarification purpose.
> >
> >[OLD]
> >   A mid-point LSR that expands loose next-hop(s) for one or more S2L
> >   sub-LSP path(s), and that receives a Path message with the "P2MP-TE
> >   Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE
> >   LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the
> >   P2MP-TE LSP.
> >
> >[NEW]
> >   A mid-point LSR that expands loose next-hop(s) for one or more S2L
> >   sub-LSP path(s), and that receives a Path message with the "P2MP-TE
> >   Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE
> >   LSP tree by re-evaluating all S2L sub-LSP(s) that are expanded paths
> >   of the loose next-hop(s) of the P2MP-TE LSP.
> >
> >
> >5. Section 3, third paragraph (towards the end).
> >
> >[snip]
> >   In this case, the mid-point LSR that expands loose next-
> >   hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L
> >   sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to
> >   the ingress node.
> >[snip]
> >
> >Similar to comment #3 above, it may be beneficial to clarify the reason
> >behind specifying one or more S2L sub-LSPs, i.e. to specify the
> >sub-groups.
> >
> >
> >6. There's also a typo in the Security Considerations section.
> >
> >[OLD]
> >it may be desirable for a a mid-point LSR to modify
> >
> >[NEW]
> >it may be desirable for a mid-point LSR to modify
> >
> >[NOTE]
> >s/a a /a /
> >
> >
> >Thanks!
> >
> >-Nobo
> >
> >> -----Original Message-----
> >> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> >> Sent: Wednesday, July 30, 2014 6:10 AM
> >> To: [email-masked]; [email-masked]; VIGOUREUX, MARTIN
> >> (MARTIN); [email-masked]
> >> Subject: [mpls] poll to see if we have support to make
> >> draft-tsaad-mpls- p2mp-loose-path-reopt an mpls wg doc
> >>
> >> Working Group,
> >>
> >> This is to start a two week poll on adopting
> >> draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group
> >> document.
> >>
> >> Please send your comments (support/not support) to the mpls working
> >>group mailing list ([email-masked]). Please give a technical motivation
> >>for  your support/not support, especially if you think that the
> >>document should  not be adopted as a working group document.
> >>
> >> There is one IPR claim against this document.
> >>
> >> The authors and contributors has stated on the working group mailing
> >>list  that they are not aware of any other IPR claims against this
> >>draft.
> >>
> >> However if you are on the the mpls working group mailing list and
> >>aware of  IPR that relates to this draft, the time to disclose this is
> >>now.
> >>
> >> This poll ends August 14, 2014.
> >>
> >> /Loa
> >>
> >> for the MPLS wg co-chairs
> >> --
> >>
> >>
> >> Loa Andersson                        email: [email-masked]
> >> Senior MPLS Expert                          [email-masked]
> >> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >_______________________________________________
> >mpls mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/mpls
> >