Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
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
> [e-mail]
> 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