Re: [Mpls-interop] moving mpls-tp documents - you are supposed torespond

["Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>]

Hi,

Please see inline.

Best regards,

Nurit

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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,

 

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?)      

<NS> Support <NS>

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

<NS> Support <NS>

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

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

      

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

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

 

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

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

 

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

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

      

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

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

 

draft-busi-mpls-tp-oam-framework      (update based on Ipswich

                                        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>

      

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

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

 

draft-ietf-mpls-tp-framework          (prepare for a wg last call, after

                                        the tp-requirements are wg last

                                        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>

 

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)

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

 

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

<NS> Support <NS>

 

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

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

 

draft-sprecher-mpls-tp-oam-analysis   (update as soon as the

                                        oam-requirements are stable)

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

 

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

                                        be republished)

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

 

draft-yang-mpls-tp-ring-protection

-analysis                             (accept as a MEAD team doc?)

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

 

As a member of the MEAD team you are expected to respond to the

"accept as a MEAD team doc"?

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

 

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.

<NS> I will <NS>

 

As an editor you are supposed to take the action (when the time is

right) for the other document.

<NS> I will <NS>

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:  [phone]

 

                                       email:  [e-mail]

                                               [e-mail]

                                               [e-mail]

 

 

_______________________________________________

Mpls-interop mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/mpls-interop

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