Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework

From: Lou Berger <[email-masked]>
Date: Tue, 01 Feb 2011 15:18:55 -0500

Julien,
	Thank you for the comments!  Please see below for responses.

On 1/31/2011 6:54 PM, Julien Meuric wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review. The purpose
> of the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-ccamp-mpls-tp-cp-framework-05
> Reviewer: Julien Meuric
> Review Date: 31 January 2011
> IETF LC End Date: 31 January 2011
> Intended Status: Informational
>
> *Summary:*
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
> *Comments:*
> This document is clearly written and easy to understand, even if the
> reader does not go over the numerous references.
>
> *Major Issues:*
> No major issues found.
>
>
> *Minor Issues:* (leaving out acronym expansion or references to add
> already highlighted by the AD)
> ----------
> Section 1.3
> Quoting Adrian (by the way: congratulations!): "A reference to
> draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of
> UNIs and NNIs." Indeed, but it requires more than a reference: since the
> aforementioned I-D only defines "service interfaces", a little
> elaboration on the use of "NNI" in draft-ietf-ccamp-mpls-tp-cp-framework
> is needed.

I'm not sure what you're looking for here.  The revised 1.3 now reads:

1.3. Reference Model

    The control plane reference model is based on the general MPLS-TP
    reference model as defined in the MPLS-TP framework [RFC5921] and
    further refined in MPLS-TP User-to-Network and Network-to-Network
    Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP
    framework [RFC5921], the MPLS-TP control plane is based on GMPLS with
    RSVP-TE for LSP signaling and targeted LDP for PW signaling.  In both
    cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic
    routing within an MPLS-TP domain.

The draft also says:

4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI)

    The majority of GMPLS control plane related RFCs define the control
    plane from the context of an internal network-to-network interface
    (I-NNI).  In the MPLS-TP context, some operators may choose to deploy
    signaled interfaces across user-to-network (UNI) interfaces and
    across inter-provider, external network-to-network (E-NNI),
    interfaces.  Such support is embodied in [RFC4208] for UNIs and
    [RFC5787] for routing areas in support of E-NNIs.  This work may
    require extensions in order to meet the specific needs of an MPLS-TP
    UNI and E-NNI.

What else would you like to see covered?

> ----------
> Section 2.1
> Requirement 17 looks like a tautology. Requirement 19 in RFC 5654
> clarifies the intend, but I am not sure it is needed here more than "A
> control plane must not be required to support coffee making".

Given the number of times the optional nature of CP in TP, it seems 
appropriate to have [RFC5654, requirement 19] reflected in this 
document.  Would you like to suggest alternate phrasing or can you live 
with what's there?

>
> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous"
> domains, but I do not think it is defined. Would my domain with all my
> 640 Mb/s switching capacity nodes be homogeneous?
>

I agree with your comment, but it really applies to RFC5654 as we're 
just quoting that RFC.

> I believe requirement 24 also covers 27.C from RFC 5654.
>

agreed!

> Requirement 39 mentions ASON: I thought the scope of ASON was
> circuit-switched technologies, has it been extended for packet-switched?
>

This too is directly from RFC 5654.  How about "ASON(control plane) 
architecture."?

> Requirement 62 states "this should be the default": I guess "this"
> refers to bidirectional, but I believe the wording should be improved.
>

Okay, rephrased:

     The MPLS-TP control plane must support 1:n bidirectional
     protection for P2P transport paths. Bidirectional 1:n protection
     should be the default for 1:n protection [RFC5654, requirement 67
     A].

> Requirement 65 says "the control plane may support extra-traffic": not
> sure what is means (extra traffic over the control network?).

Okay, rephrased:
     The MPLS-TP control plane may support the control of extra-traffic
     type traffic [RFC5654, note after requirement 67].

> ----------
> Section 4.2.1
> It is consistent to section 2 of RFC 5951: an explicit reference could
> be added, especially when considering the title of that RFC...

okay, reference added.

> ----------
> Section 4.3 and 5.2
> Not sure about the dashes following the numbers: should not they be in
> the right column instead of the left one?
>

I think the current is clear as hyphens typically are at the trailing 
end of a line break.  But I also can't get excited about so will add 
leading (in addition to trailing) if you think it's needed.

> It is a bit surprising to see explicitly "proper vendor implementation"
> while it is should be implicit for any standard specification...

This was added after a specific discussion.  Unfortunately, I really 
don't recall the specifics of the discussion/objection.  I suspect it 
was rooted in the differences in scope between ITU and IETF specifications.

> ----------
> Section 5.3.2: "If the control plane is physically separated...
> information".
> I do not believe this paragraph is needed here: no other section
> mentions that sub-case (which might be in the scope of the ForCES WG).

Agreed!

> ----------
> Section 4.2.1 focuses on "Management Plane Support" within the "4. TE
> LSPs" section. The same kind of paragraph is expected in the "5.
> Pseudowires" section but is currently missing.
> ----------
>

Okay, will add something...

>
> *Nits:*
> ----------
> Section 1.2
> s/over LSP based/over LSP-based/

okay.

> ----------
> Section 2.3
> s/customer/client/
RFC5860 says "customer"

> ----------
>    Section 4.1.1
> s/control (and management) planes/control (and management) plane(s)/

I think the original is correct, but will defer to the RFC editor.

> ----------
> Section 4.1.2
> s/and consequently, MPLS-TP uses/and consequently MPLS-TP, uses/
okay.
> s/control (and management) planes/control (and management) plane(s)/
see above.

> ----------
> Section 4.1.4.1 (interesting concepts)
> s/(PCE) Based approaches/(PCE)-based approaches/
okay
> s/PCE requests and responses/requests to and responses from PCE/
s/PCE requests and responses/ PCE related requests and responses/

> ----------
> Section 4.1.9
> s/LSPs as discussed in [TP-SURVIVE], is/LSPs, as discussed in
> [TP-SURVIVE], is/
okay
> ----------
> Section 4.2.1.2
> s/the life, (traffic hit/the life (traffic hit/
okay
> ----------
> Section 4.4.4
> s/but nonetheless, must/but nonetheless must/
s/but nonetheless, must/but, nonetheless, must/
> ----------
> Section 4.4.5
> s/OAM related/OAM-related/ (twice)
sure
> ----------
> Section 4.4.6
> s/Diffserv enable/Diffserv-enabled/transport
> s/Diffserv related/Diffserv-related/
sure.

> ----------
> Section 4.4.8
> s/entity related/entity-related/
ditto
> ----------
> Section 5.3.1
> s/to be, theoretically, a straightforward exercise/to be a
> straightforward exercise/ (unless there is a strong reason to keep it
> theoretical)
well, until we actually do the work, one cannot be sure.  (Left as written.)

> ----------
> Section 5.3.5
> s/transport service require OAM/transport service requires OAM/
thanks.
> s/performance related monitor/performance-related monitor/
> ----------
sure.
> Section 6
> s/MPLS and GMPLS related/MPLS- and GMPLS-related/
> ----------
Okay.

Much thanks,
Lou

> Regards,
> Julien

---

From: Julien Meuric <[email-masked]>
Date: Thu, 03 Feb 2011 01:49:19 +0100

Hi Lou.

I think we agree on all the nits (the RFC editor will act as an arbitror 
for the brackets), so please find below my answers on remaining comments.

Regards,

Julien

> On 1/31/2011 6:54 PM, Julien Meuric wrote:
[...]
> What else would you like to see covered?
I think everything is covered, it is more a matter of clarification (in 
the spirit of the explicit "proper vendor implementation" below). 
[RFC5921] and [TP-UNI] define "Transport Service Interface", "NNI 
service interface" or "Transport Path CP"; whereas in the 3rd paragraph 
of your section 1.3 you introduce an "LSP NNI". Even though the latter 
self-describes, I think it deserves a (short) explicit 
explanation/definition.
What is more [TP-UNI] mentions only signaling over NNI: maybe it should 
be updated to actually be a consistent model for the CP framework... 
(Who in the routing directorate was in charge of reviewing that?)

> document.  Would you like to suggest alternate phrasing or can you 
> live with what's there?
>
I feel the phrasing in RFC 5654 is clearer. An alternative could be: 
"The presence of a control plane must not be required for static 
provisioning."

> I agree with your comment, but it really applies to RFC5654 as we're 
Indeed. Do you or the AD think I should submit new RFC errata? I fear it 
may not remove the homogeneous fog...

> This too is directly from RFC 5654.  How about "ASON(control plane) 
It would not change much, but would be better anyway.

>     should be the default for 1:n protection [RFC5654, requirement 67
Perfect!

>     type traffic [RFC5654, note after requirement 67].
"the control of extra-traffic" would be enough to address my comment, 
but if you like.

> leading (in addition to trailing) if you think it's needed.
Leading might improve the reading.

> was rooted in the differences in scope between ITU and IETF 
No harm done by writing it anyway (just unusual in IETF).

[...]

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Thu, 3 Feb 2011 02:05:55 +0000

Julien, Lou,

Let me see if I can help clarify this point:

On 3 Feb 2011, at 00:49, Julien Meuric wrote:
>> I agree with your comment, but it really applies to RFC5654 as we're just quoting that RFC.
>> 
> Indeed. Do you or the AD think I should submit new RFC errata? I fear it may not remove the homogeneous fog...
> 

In this context it means that the domains that are homogeneous with one another, not that the nodes within a single domain are homogeneous.

Requirement 25 in 5654 is meant to convey that it MUST be possible to set up E2E transport paths across multiple MPLS-TP domains where each all the domains are homogeneous, i.e. they all use (a separate instance of) the same control plane protocols.

Requirement 26 in 5654 is meant to convey that it SHOULD be possible to set up E2E transport paths across multiple MPLS-TP domains where all the domains are not homogeneous, i.e. they do not all use (a separate instance of) the same control plane protocols, e.g. some may use a control plane and other may use a management plane.

Requirement 26 was inserted at the request of Andy (on behalf of Verizon) and Greg Mirsky asked for clarification on the meaning in this e-mail thread: http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html 

>>> circuit-switched technologies, has it been extended for packet-switched?

I am not an ASON expert and wasn't involved in the development of the ASON Recommendations but my understanding is that prior to "ASON" the architecture was referred to as ASTN (Automatically Switched Transport Network), at some point ITU updated the Recommendation and also changed the terminology to ASON but the change from "Transport" to "Optical" wasn't meant to imply a limitation of the scope of the architecture and it is my understanding that ITU-T considers ASON an appropriate architecture for all transport networks be they optical, circuit switched or packet switched.

If you want song and verse on the history then someone like Italo or Maarten Vissers can probably provide it or point you to someone who was involved at the time and can provide the full history and assumed applicability.

HTH
Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 2 Feb 2011 20:11:42 -0600

Ben,
Thanks a lot for the clarification.
Luyuan

-----Original Message-----
From: Benjamin Niven-Jenkins [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2011 9:06 PM
To: Julien Meuric
Cc: Lou Berger; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework

Julien, Lou,

HTH
Ben

---

From: Lou Berger <[email-masked]>
Date: Thu, 03 Feb 2011 17:54:54 -0500

Julien,
	See below.

> self-describes, I think it deserves a (short) explicit

Humm, I'm not sure what an LSP NNI is, so now just reads NNI to be 
consistent with 5921.

> (Who in the routing directorate was in charge of reviewing that?)

no idea.

> "The presence of a control plane must not be required for static

now says:
   The presence of a control plane must not be required for static
   provisioning of MPLS-TP transport paths. [RFC5654, requirement
   19].

> may not remove the homogeneous fog...

See response from Ben.

> No harm done by writing it anyway (just unusual in IETF).

Much thanks!

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 03 Feb 2011 18:38:43 -0500

Ben,

This is really helpful.  does this reflect your intent:

      21. The MPLS-TP control plane must work across multiple homogeneous
          domains [RFC5654, requirement 25], i.e., all domains use the
          same MPLS-TP control plane.

      22. The MPLS-TP control plane should work across multiple non-
          homogeneous domains [RFC5654, requirement 26], i.e., some
          domains use the same control plane and other domains use static
          provisioning.

Lou

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Fri, 4 Feb 2011 00:30:48 +0000

>         domains use the same control plane and other domains use static

Yes, but...

How much ambiguity/accuracy do you wish to avoid Vs how wordy (and possibly unwieldy) do you want to make the requirement which itself risks additional ambiguity?

What I mean is "same MPLS-TP control plane" is really "same (but different instances of) MPLS-TP control plane" because if it was just the "same control plane" then it would be a single (control plane) domain.

However, that makes the wording and sentence construction start to become ugly and risks causing more confusion than it clarifies, so maybe I shouldn't have opened that can of worms...

Anyway, I'm OK with your proposal, but I would have been OK with the wording in 5654 as well :-)

I guess it's really up to Julien & the ADs and I'll point out that Adrian is normally pretty good at wordsmithing this sort of thing if that's the route you want to take.

Ben "call me pedant" N-J

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 3 Feb 2011 19:39:03 -0500

Lou,

With regards to 22, there are probably three cases that we'll see in
practice:

1. Fully dynamic GMPLS control plane for LSP setup, very similar to how
MPLS-TE is now used in conjunction with external planning tools, or perhaps
MPLS-TP LSP setup initiated as a result of UNI signaling.

2. An equivalent to ATM SPVCs, where an operator initiates, via an NMS
command, an MPLS-TP LSP that either just specifies the endpoints, or a loose
source route, and GMPLS signaling actually instantiates the LSP in the
network.

3. NMS-controlled PVC setup, perhaps by using SNMP or another management
protocol to install state in every cross-connect in the LSP path, or some
other static provisioning mechanism.

The point of #22 is that if operator A is using one of these three methods
for LSP setup, and operator B is using a different method, it should still
be possible to set up LSPs that span both networks.

Cheers,
Andy

On 2/3/11 18:38 , "Lou Berger" <[email-masked]> wrote:

>> In this context it means that the domains that are homogeneous with one
>> another, not that the nodes within a single domain are homogeneous.
>> 
>> Requirement 25 in 5654 is meant to convey that it MUST be possible to set up
>> E2E transport paths across multiple MPLS-TP domains where each all the
>> domains are homogeneous, i.e. they all use (a separate instance of) the same
>> control plane protocols.
>> 
>> Requirement 26 in 5654 is meant to convey that it SHOULD be possible to set
>> up E2E transport paths across multiple MPLS-TP domains where all the domains
>> are not homogeneous, i.e. they do not all use (a separate instance of) the
>> same control plane protocols, e.g. some may use a control plane and other may
>> use a management plane.
>> 
>> Requirement 26 was inserted at the request of Andy (on behalf of Verizon) and
>> Greg Mirsky asked for clarification on the meaning in this e-mail thread:
>> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html
>> 
>> I am not an ASON expert and wasn't involved in the development of the ASON
>> Recommendations but my understanding is that prior to "ASON" the architecture
>> was referred to as ASTN (Automatically Switched Transport Network), at some
>> point ITU updated the Recommendation and also changed the terminology to ASON
>> but the change from "Transport" to "Optical" wasn't meant to imply a
>> limitation of the scope of the architecture and it is my understanding that
>> ITU-T considers ASON an appropriate architecture for all transport networks
>> be they optical, circuit switched or packet switched.
>> 
>> If you want song and verse on the history then someone like Italo or Maarten
>> Vissers can probably provide it or point you to someone who was involved at
>> the time and can provide the full history and assumed applicability.
>> 
>> HTH
>> Ben
>> 
>> 
>> 
>> 
>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 04 Feb 2011 10:09:03 -0500

Andy,
	So you're saying we have SVCs, PVCs, and SPVCs.  I agree.  But note 
that from an inter-domain perspective, there's no difference between the 
latter two cases as both use static provisioning at the domain boundary.

How about:

      22. The MPLS-TP control plane should work across multiple non-
          homogeneous domains [RFC5654, requirement 26], i.e., some
          domains use the same control plane and other domains use static
          provisioning at the domain boundary.

Lou

On 2/3/2011 7:39 PM, Malis, Andrew G. (Andy) wrote:
> On 2/3/11 18:38 , "Lou Berger"<[email-masked]>  wrote:
>
>>
>> Ben,
>>

---

From: Julien Meuric <[email-masked]>
Date: Fri, 04 Feb 2011 16:54:43 +0100

Hi Lou.

I also feel it is clearer this way.

Thanks,

Julien

Le 04/02/2011 16:15, Malis, Andrew G. (Andy) a écrit :
> Lou,
>
> That sounds good to me, thanks.
>
> Cheers,
> Andy
>
> On 2/4/11 10:09 , "Lou Berger"<[email-masked]>  wrote:
>
>> Andy,

---

From: Julien Meuric <[email-masked]>
Date: Fri, 04 Feb 2011 17:09:44 +0100

Hi Ben.

It is nice to have the editor of RFC 5654 on this thread.

About the homogeneity, I believe Lou's latest proposal will address the 
issue.

About ASON, my initial comment was not based on the title. If you look 
at [ITU.g8080.2006], the section "scope" says:
"applicable to SDH transport networks, as defined in ITU-T Rec. G.803, 
and Optical Transport Networks, as defined in ITU-T Rec. G.872".
However, I had a check on [ITU.g8080.2008] since your feedback and found:
"applicable to connection-oriented circuit or packet transport networks, 
as defined in [ITU-T G.805]".
In other words: my comment was irrelevant, but the answer does not lie 
in the titles (more a matter of releases). I think we're even, aren't 
we? One beer for each! ;-)

Cheers,

Julien

Le 03/02/2011 03:05, Benjamin Niven-Jenkins a écrit :
> >>> Requirements 21 and 22 refers to "homogeneous" and "non
> >>> homogeneous" domains, but I do not think it is defined. Would
> >>> my domain with all my 640 Mb/s switching capacity nodes be
> >>> homogeneous?
> >>>
> >>
> > Indeed. Do you or the AD think I should submit new RFC errata? I
> > fear it may not remove the homogeneous fog...
> >
>
>  In this context it means that the domains that are homogeneous with
>  one another, not that the nodes within a single domain are
>  homogeneous.
>
>  Requirement 25 in 5654 is meant to convey that it MUST be possible to
>  set up E2E transport paths across multiple MPLS-TP domains where each
>  all the domains are homogeneous, i.e. they all use (a separate
>  instance of) the same control plane protocols.
>
>  Requirement 26 in 5654 is meant to convey that it SHOULD be possible
>  to set up E2E transport paths across multiple MPLS-TP domains where
>  all the domains are not homogeneous, i.e. they do not all use (a
>  separate instance of) the same control plane protocols, e.g. some may
>  use a control plane and other may use a management plane.
>
>  Requirement 26 was inserted at the request of Andy (on behalf of
>  Verizon) and Greg Mirsky asked for clarification on the meaning in
>  this e-mail thread:
>  I am not an ASON expert and wasn't involved in the development of the
>  ASON Recommendations but my understanding is that prior to "ASON" the
>  architecture was referred to as ASTN (Automatically Switched
>  Transport Network), at some point ITU updated the Recommendation and
>  also changed the terminology to ASON but the change from "Transport"
>  to "Optical" wasn't meant to imply a limitation of the scope of the
>  architecture and it is my understanding that ITU-T considers ASON an
>  appropriate architecture for all transport networks be they optical,
>  circuit switched or packet switched.
>
>  If you want song and verse on the history then someone like Italo or
>  Maarten Vissers can probably provide it or point you to someone who
>  was involved at the time and can provide the full history and assumed
>  applicability.
>
>  HTH Ben
>
>

---

From: Julien Meuric <[email-masked]>
Date: Fri, 04 Feb 2011 17:14:54 +0100

Hi again Lou.

It looks like my comments on your I-D were addressed. Let us defer to 
the ADs about my question on updating draft-ietf-mpls-tp-uni-nni...

Thanks,

Julien

---

From: Lou Berger <[email-masked]>
Date: Fri, 04 Feb 2011 11:19:32 -0500

All (including co-authors),
	A version with all edits to date is available at http://labn.net/docs/.
   The diff version is at:
http://labn.net/docs/draft-ietf-ccamp-mpls-tp-cp-framework-06-preview-2011-02-04-from-5.diff.html

I will submit on Tuesday AM if if no comments / changes are received.

Lou

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Fri, 4 Feb 2011 10:15:58 -0500

Lou,

Cheers,
Andy

On 2/4/11 10:09 , "Lou Berger" <[email-masked]> wrote:

>>>> Maarten