Re: [mpls-tp] [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02

[Lou Berger <[e-mail]>]

Eric,
	Thank you for the comments.  Please see below for in-line responses.

On 7/12/2010 10:33 AM, Eric Osborne (eosborne) wrote:
> I have a few questions.  Nothing major, as the draft is in general
> pretty solid.
>
>
>
> 1) Section 4.1 reviews existing GMPLS functionality and describes
> applicability to TP.  Section 4.1.8 defines LSP hierarchy but doesn't
> say anything about how it applies to TP.  It probably needs a line like
> "Hierarchical LSPs may be used in MPLS-TP at the discretion of the
> network operator" or something similar ot what's in other subsections of
> 4.1.
>

Good point!  Something along the lines of the following will be added:

   LSP hierarchy is expected to play an important role in MPLS-TP
   networks, particularly in the context of scaling and recovery.

>
> 2) Some of section 4.1.9 is out of sync with the surviveability
> framework (draft-ietf-mpls-tp-survive-fwk)
>
>   - survive-fwk draws a distinction between protection and restoration
> that  cp-framework lumps under 'recovery'.  It may be worth calling out
> both protection and restoration as separate things.

This is a carry over from GMPLS terminology, see [RFC4427], [RFC4426], 
[RFC4872], [RFC4873]

>
> - Section 4.1.9 lists five recovery types:
>
>       - 1+1 bidirectional protection for P2P LSPs
>       - 1+1 unidirectional protection for P2MP LSPs
>       - 1:n (including 1:1) protection with or without extra traffic
>       - Rerouting without extra traffic (sometimes known as soft
>         rerouting), including shared mesh restoration
>       - Full LSP rerouting
>
>
> I don't see where these five types come from.

from GMPLS.  The five types should be identified in that context and can 
be used to support [TP-SURVIVE].  The text should make this more clear.

> rfc5654 requirements R65
> and R67 list five MUST types (bidir 1+1 p2p, unidir 1+1 p2p, unidir 1+1
> p2mp, bidir 1:n p2p, unidir 1:n p2mp) and one optional (undir 1:n p2p).
> R68 requires 1:n (including 1:1) ahread mesh recovery.
>
> How do the five types in section 4.1. 9 map to the requirements in
> rfc5654?

I must be missing something.  This looks like a straightforward mapping. 
  (The table also shows mapping of requirements to mechanisms) for example:

At first glance I don't see unidir 1+1 p2p in sec. 4.1.9,

it's the second in the list.

> although perhaps it's implied in 'rerouting without extra traffic'.
> 'Full LSP rerouting' also seems like it may mean something specific to
> whomever wrote it but as far as I can tell there's no explicit
> definition of 'Full LSP rerouting' (as opposed to partial?  as opposed
> to something other than rerouting?) anywhere in rfc5654 or survive-fwk.
> And 'soft rerouting appears to be survive-fwk's 'soft restoration'.
>
> 3) Section 4.1.9, "it's use is not precluded" , s/it's/its/
>

Thanks!

>
> 4) Section 4.4.1 is entitled "MPLS to MPLS-TP Interworking".  The
> section talks about " interworking of MPLS-TE and GMPLS control plane",
> so shouldn't the section be "MPLS-TE to MPLS-TP Interworking"?  Unless
> things like LDP-to-TP interworking are in someone's plans, I think "TE
> to TP Interworking" is a better fit.

Agreed.  Changed to "MPLS-TE to MPLS-TP LSP Control Plane Interworking"

Thanks again!

Lou
>
>
>
>
>
>
>
> eric
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>