Subject: [PWE3] Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 12 Jul 2010 09:33:12 -0500

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.

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.

- 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.  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?  At first glance I don't see unidir 1+1 p2p in sec. 4.1.9,
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/

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.

eric

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Jul 2010 17:19:44 -0400

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

> network operator" or something similar ot what's in other subsections of

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.

> both protection and restoration as separate things.

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

> 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
> 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.

> 3) Section 4.1.9, "it's use is not precluded" , s/it's/its/

Thanks!

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>