Subject: [Mpls-interop] moving mpls-tp documents - you are supposed to respond

From: Loa Andersson <[email-masked]>
Date: Fri, 23 Jan 2009 16:57:13 +0100

I'll to try push the next round of documents to wg last call,
or have them accepted as wg documents asap. The discussions in
Ipswich gave a of input that should be captured in several
documents.

This also means that we need to to have a couple of documents
become wg documents. Here are the steps we need to take:

draft-andersson-mpls-tp-oam-def       (accept as a MEAD team doc?)  	
draft-beller-mpls-tp-gach-dcn 	      (accept as a MEAD team doc?)
draft-boutros-mpls-tp-cv              (accept as a MEAD team doc?)
  	
draft-boutros-mpls-tp-fault           (accept as a MEAD team doc?) 	
draft-boutros-mpls-tp-loopback 	      (comments and review need!) 	
draft-boutros-mpls-tp-performance     (accept as a MEAD team doc?)
  	
draft-bryant-mpls-tp-ach-tlv          (accept as a MEAD team doc?) 	
draft-busi-mpls-tp-oam-framework      (update based on Ipswich
                                        discussion!) 	
draft-gray-mpls-tp-nm-req             (accept as a wg doc!)

draft-ietf-mpls-tp-framework          (prepare for a wg last call, after
                                        the tp-requirements are wg last
                                        called)
draft-ietf-mpls-tp-oam-requirements   (we need to get existing comments
                                        written down, we will allow until
                                        Friday Jan 30 to do this, after
                                        that we'll prepare the doc for wg
                                        last call)
draft-ietf-mpls-tp-requirements       (prepare for wg last call)

draft-martinotti-mpls-tp-interworking (accept as a MEAD team doc?) 	
draft-sprecher-mpls-tp-oam-analysis   (update as soon as the
                                        oam-requirements are stable)
draft-sprecher-mpls-tp-survive-fwk    (document has expired and should
                                        be republished)

draft-yang-mpls-tp-ring-protection
-analysis                             (accept as a MEAD team doc?)

As a member of the MEAD team you are expected to respond to the
"accept as a MEAD team doc"?

As a a MEAD team member you are expected to supply your comments on
draft-ietf-mpls-tp-oam-requirements on Fri Jan 30, the latest.

As an editor you are supposed to take the action (when the time is
right) for the other document.

A reminder:

Becoming a MEAD team document means that there a strong element
in that draft that the MEAD needs to coordinate, it won't stop
us from splitting or merge documents, just that we will do so
in a coordinated way.

Becoming wg documents means positive response to three questions.

- does this document address a problem that the wg needs to
   solve
- is this document a good enough start to solve this problem
- is it within wg charter

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 23 Jan 2009 17:17:06 +0100

By when are you expecting us to reply to the "accept as a MEAD team doc"
question?

Thanks and have a nice week-end

Italo 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Friday, January 23, 2009 4:57 PM
> To: MEAD team
> Subject: [Mpls-interop] moving mpls-tp documents - you are 
> supposed torespond
> 
> All,
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 23 Jan 2009 08:21:46 -0800

As always with "sooner is better", but there are no other time
limit than what is practical with respect to a certain document.

But if you drag out to long you always risk that I make another
call of consensus than what you'd wanted and then you have to
live with it.

/Loa
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI ITALO
Sent: Friday, January 23, 2009 5:17 PM
To: Loa Andersson; MEAD team
Subject: Re: [Mpls-interop] moving mpls-tp documents - you are supposed torespond

Loa,

Italo

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Jan 2009 17:03:29 -0000

> draft-andersson-mpls-tp-oam-def       (accept as a MEAD team doc?)

Yes. But will need significantly more work once accepted.

> draft-beller-mpls-tp-gach-dcn       (accept as a MEAD team doc?)

Yes. Addresses a requirement. But will need some more details once accepted.
(I am a co-author)

> draft-boutros-mpls-tp-cv              (accept as a MEAD team doc?)

Not oposed.
I have some confusion about the control plane aspects of this draft.

> draft-boutros-mpls-tp-fault           (accept as a MEAD team doc?)

No, not yet.
This I-D is quite significantly different from the way faults are handled 
and notified in GMPLS (the candidate control plane) and some convergence is 
desirable.

> draft-boutros-mpls-tp-loopback       (comments and review need!)

No, not yet.
I do not see that the requirements for this work are present in the OAM 
requirements.

> draft-boutros-mpls-tp-performance     (accept as a MEAD team doc?)

No, not yet.
The OAM requirements for performance measurement and reporting do not have 
consensus (IMHO).

> draft-bryant-mpls-tp-ach-tlv          (accept as a MEAD team doc?)

I am wary of a document that defines specific TLVs without describing their 
use. Indeed this use is defered to other documents without reference. This 
means that specific TLVs may be being created without a valid use, or in a 
format that cannot be used.

Better to move the definition of the TLV structure, the IANA registry, and 
the Null TLV into [GAL-GACH] and to move the definition of the specific TLVs 
into their own I-Ds.

If that happens, this I-D should be deleted.

> draft-busi-mpls-tp-oam-framework (update based on Ipswich discussion!)

Yes, but only after updates are submitted.

> draft-gray-mpls-tp-nm-req (accept as a wg doc!)

Yes, but only after Ipswich updates are submitted.

> draft-ietf-mpls-tp-framework
> (prepare for a wg last call, after the
>   tp-requirements are wg last called)

Believe this would be very premature.
The f/w cannot describe many of the MPLS-TP functions as they have not been 
developed yet.
We should keep updating this document until the MPLS-TP scenery is in focus.

>                                        that we'll prepare the doc for wg

Sorry, is this a last call for comments that need to be in before a last 
call for comments can be issued?

> draft-ietf-mpls-tp-requirements       (prepare for wg last call)

Agree, but will need substantial input from ITU before last call.

> draft-martinotti-mpls-tp-interworking (accept as a MEAD team doc?)

No, not yet.
I do not believe that many of these scenarios are within scope.
We are (still!) waiting for a set of deployment scenarios from the ITU.

>                                        oam-requirements are stable)

Agreed. Work in progress.

> draft-sprecher-mpls-tp-survive-fwk    (document has expired and should

In hand.

> draft-yang-mpls-tp-ring-protection-analysis
>                             (accept as a MEAD team doc?)

No.
Useful background material and input to draft-sprecher-mpls-tp-survive-fwk, 
but not needed as an RFC.

> "accept as a MEAD team doc"?

I did.

> draft-ietf-mpls-tp-oam-requirements on Fri Jan 30, the latest.

I will.

> right) for the other document.

I plan to.

Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 24 Jan 2009 18:35:23 +0100

Hi,

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Loa Andersson
Sent: Friday, January 23, 2009 17:57
To: MEAD team
Subject: [Mpls-interop] moving mpls-tp documents - you are supposed torespond

All,

documents.

<NS> Support <NS>

<NS> Support <NS>

<NS> In the OAM requirement draft we have a requirement for Continuity and Connectivity Verification. There are references for p2p and p2mp, on-demand and protective modes......etc. We have specific description of the behavior of MEPs and MIPs.......

We definitely need a tool to address the requirements for CC&V. 

We can accept the document once it is clear it addresses a requirement of the OAM requirement draft. We need to see which requirement it addresses (if the authors believe a dedicated tool is needed for CV only they need to discuss it first in the context of the OAM requirements. As I recall it we had confusion and a long discussion on the CC and CV functions and the decision was to combine these to functions into one CC&V. The OAM requirement draft as well as the framework and the analysis documents were updated to align with this conclusion. We can re-open the discussion but in the right context.

Also I am not sure the draft addresses the requirement for CV as defined in the OAM requirements draft but the one for route determination (route trace). It is not clear in which modes it works (on demand? Proactive?). 

It is not clear how it works for P2MP. I am not sure it is clear how we differentiate between a message sent to a MEP and a one sent to a MIP. In the way the document is describes, all LSRs along the path are considered as MIPs and always pick a message with TTL=1, handles it and forward it to the next hop setting the TTL to 1. In the requirement draft we can send a message to a specific MIP and we do not request it to forward the message further. 

I propose the author addresses these and other comments we sent them and then we can accept the document. 

In any case, even when accepted, we need to review first the framework and the analysis drafts. <NS>

<NS> I did not have the chance to look at the document yet. I'll review it and come back. <NS>

<NS> There is no requirement in the OAM requirement draft for a loopback tool. I propose to discuss it first in the context of the OAM requirements. If there is a consensus that such a tool is required, we should update the analysis draft and have such a document. <NS>

<NS> I did not have the chance to look at the document yet. I'll review it and come back. <NS>

<NS> Yes in principle. The document needs (1) to be updated to remove the A bit (although I am not happy to see an empty TLV even if there is no need for TLV. I would prefer a more elegant way to identify if the packet includes ACH TLV. For me it looks like having an EThertype of MPLS and leave the MPLS header empty). (2) The document should be extended to include a domain-wide unique identifier for a LSP (src address, dest address and connection/path id which is unique in the context of src and dest). We need such for IPV4 and one for IPv6 and maybe other types as well. (3) include a description of some application/usage of each TLV <NS>

                                        discussion!)

<NS> no need to support here. Right? This is already a MEAD document. Or maybe you ask about moving it to WG document. I would support this. <NS>

<NS> Support. Once it is accepted as a WG document, I propose to move to last call. <NS>

                                        called)

<NS> I am afraid we need to work more on this document before it goes to last call. I am concerned from the sections on OAM and survivability frameworks. I think they need just to refer to the specific documents. 

I also think that we need to discuss there the fundamental architectural elements that are needed in order to manage, monitor and protect the MPLS-TP network in different nested levels. Specifically I refer to the specific case of TC and to the general case of PST (or maybe now it is better to call it PCST (Path Concatenated Segment Tunnel). <NS>

                                        last call)

<NS> Support. Maybe it couls be useful to extend a little the section of the required functions in order to have חד משמעי understanding of the requirement. The CC&V is a good example. Specifically to CV it could be useful to indicate that we check that there is connectivity between the MEPs and we do not trace the route. <NS>

<NS> Support <NS>

<NS> Support. We still need to work on this document but it is clear that we need such a document and I think it will be beneficial to work on this in the MEAD team. <NS> 

<NS> The document is 100% aligned with the OAM requirements and framework documents. It addresses comment we got and the outcomes from Geneva. We will keep updating the document when the needed. <NS>

                                        be republished)

<NS> we will submit an updated version <NS> 

<NS> I think the input is very important for the requirement draft and the survivability document. If we decide to develop a document for ring protection, the input is very useful. Do we need a specific document for the evaluation? I do not think so. <NS>

<NS> I have just did. Will provide more answers to the two documents I did not review. <NS>

<NS> I will <NS>

<NS> I will <NS>

A reminder:

in a coordinated way.

   solve

/Loa

-- 

Loa Andersson

                                               [email-masked]

[email-masked]

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 25 Jan 2009 12:56:23 +0000

My views. Note some of my comments are based on just quickly scanning the
documents as I haven't had chance to read them all properly. Ben

> draft-andersson-mpls-tp-oam-def       (accept as a MEAD team doc?)   

Accept.

> draft-beller-mpls-tp-gach-dcn        (accept as a MEAD team doc?)

Accept

> draft-boutros-mpls-tp-cv              (accept as a MEAD team doc?)

Accept (important for MPLS-TP OAM reqs but probably need significant work to
encompass necessary requirements like P2MP etc.)

> draft-boutros-mpls-tp-fault           (accept as a MEAD team doc?)  

It is not clear to me what the scope of the draft is. It appears to define a
protection switching trigger message. It is not clear to me if this is
restricted purely to triggering protection switching or also covers a
generic FDI/BDI function? Also need to understand its relationship to
survivability framework and proposed MPLS-TP protection solutions. So I
think it's a bit premature to accept this document just yet.

> draft-boutros-mpls-tp-loopback        (comments and review need!)  

I haven't read but appears to provide a useful function, however loopback
doesn't seem to be mentioned in the OAM requirements. Need to understand
better the problem being solved and how it relates to OAM requirements
(which may just mean I need to read the draft as its already covered)

General comment of solution drafts, I think it might be useful to somehow
reference which subset of requirements a particular solution addresses.  Not
some huge copy & paste of every one from the requirements drafts, but a
pointer to a section in a requirements draft or something.

> draft-boutros-mpls-tp-performance     (accept as a MEAD team doc?)

Accept performance monitoring is a gap in current MPLS OAM capabilities.
Should the draft also discuss directional performance measurement?

> draft-bryant-mpls-tp-ach-tlv          (accept as a MEAD team doc?)

Accept
  
> draft-gray-mpls-tp-nm-req             (accept as a wg doc!)

Would support.

>                                         the tp-requirements are wg last

Following the Ipswich meeting I expect this to have some significant edits
(additional text) so would be good to have round of review before WG last
call.

> draft-martinotti-mpls-tp-interworking (accept as a MEAD team doc?)  

This document comes under "Day 2" work IMO. In other words I think the
workload is big enough already without addressing this in the "Day 1" batch
of documents. Furthermore it would benefit from having a set of initial
solutions documents before we figure out what if anything is required wrt
interworking.

> -analysis                             (accept as a MEAD team doc?)

This also comes under "Day 2" work. While it contains some useful
information I think we need to have a clear view of what general protection
looks like for MPLS-TP before digging into any ring specific mechanisms.

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Mon, 26 Jan 2009 16:21:27 +0100

Loa et all.

draft-andersson-mpls-tp-oam-def       (accept as a MEAD team doc?)
[ll>] accept as a MEAD team doc
  	
draft-beller-mpls-tp-gach-dcn 	      (accept as a MEAD team doc?)
[ll>] accept as a MEAD team doc
draft-boutros-mpls-tp-cv              (accept as a MEAD team doc?)
 [ll>] accept as a MEAD team doc

draft-boutros-mpls-tp-fault           (accept as a MEAD team doc?) 	
[ll>] accept as a MEAD team doc

draft-boutros-mpls-tp-loopback 	      (comments and review need!) 	
[ll>] accept as a MEAD team doc

draft-boutros-mpls-tp-performance     (accept as a MEAD team doc?)
[ll>] accept as a MEAD team doc
	
draft-bryant-mpls-tp-ach-tlv          (accept as a MEAD team doc?) 	
[ll>] accept as a MEAD team doc

draft-busi-mpls-tp-oam-framework      (update based on Ipswich                                     discussion!) 
[ll>] accept as a MEAD team doc

[ll>] accept as a MEAD team doc
 [ll>] accept as a MEAD team doc

draft-martinotti-mpls-tp-interworking (accept as a MEAD team doc?)
[ll>] accept as a MEAD team doc
 	
[ll>] accept as a MEAD team doc
[ll>] accept as a MEAD team doc

A reminder:

/Loa

-- 

Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Mon, 26 Jan 2009 16:23:22 +0100

Adrian,

Adrian Farrel wrote:
> Hi Loa,

<snip>
> call for comments can be issued?

no - this is not "last call comments" I just want to reach a point where
we can produce a document that is as stable as possible. Today we have
lots of requirements floating around, and some of them (as you said in
your consensus (lack of discussion). The date is just here to help the
editors get as much as possible in.

/Loa
</snip>

-- 

Loa Andersson