In message <cag4d1rf6x2u55iddngk4hwd-ozbrpexmyh4hyl9r-ao6tgo...@mail.gmail.com> Alia Atlas writes: > This email is to start a poll and discussion on whether to adopt > draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. > Please respond with opinions, comments, and whether you have read the draft. > Last IETF, there were very few people who had read the draft. > > Authors, please indicate if there is any IPR associated with this draft. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg
Alia, I know of no IPR associated with this draft. I will point out that this draft references two others: draft-villamizar-mpls-tp-multipath, and draft-villamizar-mpls-tp-multipath-te-extn which do have IPR: see http://datatracker.ietf.org/ipr/1593/ . The terms are described in the Licensing Declaration section of the IPR declaration. How this affects draft-so-yong-rtgwg-cl-framework (CL framework) is: 1. Issues of reordering within specific MPLS LSP is discussed as a potential issue in CL framework. Specifically MPLS-TP LSP cannot be reordered. If MPLS-TP LSP are carried within larger LSP, then constraints are placed on those aggregate LSPs. 2. A few solutions are proposed which include: a. Don't do that. Carry MPLS-TP LSPs separately. Don't aggregate MPLS-TP LSPs into bigger LSPs. (Note: has scaling implications, but otherwise fine). b. Refer to draft-villamizar-mpls-tp-multipath for three more options described there. i. MPLS as a Server Layer for MPLS-TP (Section 5.2.1). Expanded on in mpls-tp-multipath-te-extn. ii. MPLS-TP as a Server Layer for MPLS (Section 5.2.2). All core LSP are small and MPLS-TP. MPLS CL at edges used many edge-to-edge components. Ability to load balance at the point of congestion is lost. [Workable but poor solution]. iii. Relax MPLS-TP OAM Requirements (Section 5.2.3). Relax MPLS-TP reordering constraint but maintain order within microflows. Accept very limited OAM error. [Requires no changes except that operator ignore parts of standard in their deployment.] Many operators will tell you that 2a above is just fine. Many operators claim that they have no intention to use MPLS-TP in their core and don't need to further aggregate MPLS-TP LSP in their use of MPLS-TP (or have no intention to use MPLS-TP at all). The IPR is related to one type of forwarding change that is assumed if you opt for 2.b.i above. Since the terms of the IPR are not onerous, that should be a viable option for everyone if they choose it. Also, if you can figure out a different way to accomplish the same thing, then CL framework can remain unchanged but mpls-tp-multipath-te-extn may or may not be affected by the existance of an alternate. For the CL framework it means that a technical issue is raised for which one potential solution has IPR and that solution is described elsewhere. The technical issue remains regardless of the solution set. Other solutions are cited in CL framework. I don't consider that IPR to be related to the CL framework draft, therefore I started by saying "I know of no IPR associated with this draft." That said. Yes/support. :-) ... and I read this one too. Reason to support: The CL framework as it now stands raises numerous known but mostly solvable technical issues that arrise from the set of CL requirements, and cover a number of potential solutions for specific issues. An attempt is made to cover the full set of requirements, enumerating the requirements, categorizing them, and indicating where in the CL framework specific sets of requirements are addressed. The document calls for a number of followup documents to provide greater detail on some issues as well as documents to specify protocol extensions to address groups of related requirements. There is much in the framework document that needs further discussion within the WG, however IMHO the existing CL framework is WG chartered work item and this CL framework is a good start for that WG document. Curtis _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
