Subject: Re: [mpls-tp] [CCAMP] working group last call on draft-ietf-mpls-tp-oam-framework-05.txt

From: Curtis Villamizar <[email-masked]>
Date: Mon, 08 Mar 2010 00:04:06 -0500

In message <[email-masked]>
Loa Andersson writes:
>  
> All,
>  
>  
> this is to start a two week mpls  working group last call on
> draft-ietf-mpls-tp-oam-framework-05.txt.
>  
> Please review and send your comments to the [email-masked] mailing list.
> Please do not copy the other mailing lists this working group last call
> is announced on.
>  
> The working group last call ends March 19th.
>  
> Loa and George

I would like to request on change in "1. Introduction".

  OLD:

   In line with [13], existing MPLS OAM mechanisms will be used wherever 
   possible and extensions or new OAM mechanisms will be defined only 
   where existing mechanisms are not sufficient to meet the 
   requirements. 

  NEW:

   In line with [13], existing MPLS OAM mechanisms will be used wherever 
   possible and extensions or new OAM mechanisms will be defined only 
   where existing mechanisms are not sufficient to meet the 
   requirements.  Extensions must retain support for existing MPLS OAM
   capabilites.

Curtis

---

From: Yuji Tochio <[email-masked]>
Date: Mon, 15 Mar 2010 15:51:44 +0900

Editor's of oam-fwk,

This is my first comments on this draft:

In section 5.4, following these terminologies seem to indicate
same fucntion (i.e. Srv/MT_A)
- "MPLS-TP layer network adaption function" in 2nd para
- "the client layer adaptation function" in 3rd para

I believe they are same so that alignance should be considered.

ps to Loa,
This original e-mail is *not* sent via mpls-tp ML.... (but mpls-chairs)
I am afraid that people reading only mpls-tp ML may not notice
this wg last call.

Thanks,
Yuji

Loa Andersson wrote:
> -- 
> Loa Andersson email: [email-masked]
> Sr Strategy and Standards Manager [email-masked]
> Ericsson Inc phone: +46 10 717 52 13
> +46 767 72 92 13
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: <[email-masked]>
Date: Mon, 15 Mar 2010 08:15:22 -0000

Yuji,

I do not think there is any clarity at all in MPLS-TP on these
matters....there should be of course.  Why do I say this?

Well, a transport network should treat all clients equally (with
transparent carriage) and have a consistent adaptation function.  Not so
in MPLS-TP.  It still continues to regard IP and (rather amazingly) MPLS
LSPs as 'network layers' (a quite meaningless L3 OSI concept - this is
NOT the same as 'layer networks' which do have real meaning).  Further,
MPLS-TP still retains the notion of nested LSP sublayers (ie nested LSP
sublayers belong to the *same* MPLS-TP layer network) but also wants to
have a proper client/server relationship between nested LSPs (ie
client/server LSPs belong to *different* MPLS-TP layer networks)....and
yet we have no way to identify this distinction in the DP (I have
suggested using a well-known reserved label for this purpose, but this
simple architectural solution seems to find no favour with the equipment
vendors).

Aside=> If we did have a better understanding of these matters we would
most definitely NOT create a MS PW layer network above the MPLS-TP layer
network.  Having a largely redundant CW in the DP is bad enough on SS
PWs (this is essentially poor adaptation) but allowing these to be MS
(and thus generate another co-ps layer network) is plain madness IMO
when we are supposed to be creating a transport network.

regards, Neil 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yuji Tochio
> Sent: 15 March 2010 06:52
> To: [email-masked]
> Subject: Re: [mpls-tp] [mpls] working group last callon 
> draft-ietf-mpls-tp-oam-framework-05.txt
> 
> Editor's of oam-fwk,
> 
> In section 5.4, following these terminologies seem to 
> indicate same fucntion (i.e. Srv/MT_A)
> This original e-mail is *not* sent via mpls-tp ML.... (but 
> mpls-chairs) I am afraid that people reading only mpls-tp ML 
> may not notice this wg last call.
> 
> Thanks,
> Yuji
> 
> Loa Andersson wrote:
> > All,
> >
> >
> > Please review and send your comments to the 
> [email-masked] mailing 
> > list.
> > Please do not copy the other mailing lists this working group last 
> > call is announced on.
> >
> > Loa Andersson email: [email-masked] Sr Strategy and 
> > Standards Manager [email-masked] Ericsson Inc phone: +46 10 717 52 13
> > +46 767 72 92 13
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Loa Andersson" <[email-masked]>
Date: Tue, 16 Mar 2010 20:24:39 +0100

All,

it has been pointed out that I made the when starting the mpls
working group call on draft-ietf-mpls-tp-oam-framework-05.txt
in not copying the mpls-tp list.

Sorry if it caused any confusion.

This working group last call is therefore extended to April 1st, 2001.

/Loa

> The working group last call ends March 19th.

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///
   phone:  +46 10 717 52 13
           +46 767 72 92 13

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

---

From: Yoshinori KOIKE <[email-masked]>
Date: Fri, 19 Mar 2010 19:24:48 +0900

All,

We would like to make last call comments by quoting our
following updated draft. 
(http://tools.ietf.org/html/draft-koike-ietf-mpls-tp-oam-maintenance-points-01.html)

This procedure(merging) has already been agreed between IETF and ITU-T,
as you can see in 3.4 of the table in the following liaison document.
(https://datatracker.ietf.org/documents/LIAISON/file967.pdf)

Concretely, suggestions are as follows.

(1) reflect section 4.1.1 and 4.1.2 in our draft into section
3.3 in OAM framework-05.

(2) reflect section 4.2.1 and 4.2.2 in our draft into section
3.4 in OAM framewrok-05

(3) reflect each item of section 6 in our draft into section 5
and 6 in OAM framework-05 item-by-item

There is no new requirement. We highlighted proper specifications of 
MEP/MIP placement(both per-interface model and per-node model, both MIP 
and MEP location). The draft texts bases on and just refines and details 
the MPLS-TP OAM requirements. We hope they will serve for assistance and 
consideration for the development of OAM toolset drafts.

Best regards,

Yoshinori Koike(NTT)
Manuel Paul(Deutsche Telekom)

-- 
**************************************
Yoshinori Koike
Optical Transmission Systems Development Project
First Promotion Project
NTT Network Service Systems Laboratories
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
Telephone: +81 422 59 6723
Facsimile: +81 422 59 3494
Email: [email-masked]
**************************************

---

From: "Loa Andersson" <[email-masked]>
Date: Fri, 19 Mar 2010 21:52:15 +0100

Yoshinori,

there is subtle issue around these comments, not the technical
content (which I hope the you can reseolve with draft authors),
but the way they are addressed to both IETF and ITU.

I know we had this type of problem earlier and been able to handle
them informally, at this point where we have a dead-line coming up
in June this will a be problem.

Your comments (mail) are addressed to both the mpls-tp and the ad hoc
team maling lists, i.e. both to the IETF last call resolution process
and to the ITU-T liaison response.

If the comments are intended for the IETF last call comments resoluion
process I've will instruct the document authors to start resolving
your comments with you immediately.

If the comments are intended to be included in the ITU-T liaison, you w
ill first need to have ITU-T agreement to include them in the liaison
and once we receive the liasion the authors will sort out comments with
the responsible Rapporteur.

You will need to tell us which process you want to use for yor comments.
I don't believe it is appropriate to try to send via both channels.

/Loa

Loa Andersson

---

From: Yoshinori KOIKE <[email-masked]>
Date: Sun, 21 Mar 2010 19:52:32 +0900

Loa,

Thank you for the comment and I'm sorry for the confusion. This comment 
is intended for the MPLS WG Last Call in IETF, as I replied to your 
email for the announce of last call. Therefore, I would like you and the 
authors to start resolving the comments.

I also understand that we need a consensus in both IETF and ITU-T and 
are limited in time. I am going to take appropriate actions also in 
ITU-T to facilitate the smooth process of agreement regarding this 
comment, although I believe there will be no major issue in the comment 
which we just refined and detailed the previous agreement on MPLS-TP OAM 
MIP&MEP requirements.

Best regards,

Yoshinori

---

From: Loa Andersson <[email-masked]>
Date: Sun, 21 Mar 2010 15:15:38 -0700

Yoshinori,

thanks! Then I'll trigger the document editors to start resolving this
as a comment directed to the mpls wg last call.

Could you also notify Huub that you sent this to the ad hoc team list
for information, and that it should not be included in the ITU-T
liaison response?

/Loa

On 2010-03-21 03:52, Yoshinori KOIKE wrote:
>>>>> call

--

---

From: Yuji Tochio <[email-masked]>
Date: Sat, 27 Mar 2010 09:20:43 -0700

Hi All

In the disussion of koike draft, I had a comment that the categorize
of MEP as 3 (1 & 2) types is really reguired (as well as the case of
TCM MEP).

After looking at the slide and draft. I am convinced that per-Node
or per-IF MEP should be reconsidered by following observations.

Observations:
1) The criteria of these MEPs has dependency of the configuration
MIP and starts the working assupmtion that another MIP might be
reuqired per node where MEP is.
of the working assumption of
2) The concept Per IF/Node MIP(s) does make sense since
an intermediate node may have 1 or 2 MIP(s) in it, while
MEP shall be 1 in node.
3) From the architecture point of view, MEPs in the Ethernet
can be categorized up MEP and down MEP (See IEEE802.1ag) and
this categorize meets G.8010 and G.8121.
In that Sense, per-Node can be say either Ingress per-interface
or Egress per-Inteface. For the case where FW fuction is absent
or do-not-matter, this can be categorized as Egress following to
the port.
Note that up/down MEP is dependent of configuration of MIPs

Therefore I suggest, in stead of per-Node or per-IF MEP or
suggestion below (1) or (2) , following changes for satisfying
koike draft as one of my WG LC comments

(a) Combime 4.1 and 4.2, ie. per-node M*P or per-IF M*P, and
add the proper text for oam-fwk as titling Location of
maintenance points (= M*P).

or

(b) Change 4.1 in align with up/down MEP. That means that
the criteria is whethe MEP is facing to FW or not.

ps
For the suggestion (3), I will recosinder also and may be
addressed by the deadline of WG LC.

Thanks,
Yuji

Yoshinori KOIKE wrote:
> MEP/MIP placement(both per-interface model and per-node model, both
> MIP and MEP location). The draft texts bases on and just refines and
> details the MPLS-TP OAM requirements. We hope they will serve for
> assistance and consideration for the development of OAM toolset drafts.
>
> Best regards,
>
> Yoshinori Koike(NTT)

---

From: Yuji Tochio <[email-masked]>
Date: Sat, 27 Mar 2010 09:25:54 -0700

Hi All

Typo found....

> of MEP as 3 (1 & 2) types is really reguired (as well as the case of
(snip)

Please replace by

In the disussion of koike draft, I had a comment the categorize
of MEP as 3 (1 & 2) types is really reconsidered (as well as the
case of TCM MEP).

Sorry and Thanks,
Yuji

---

From: Yuji Tochio <[email-masked]>
Date: Thu, 01 Apr 2010 08:23:38 +0900

Hi

A few editorial comments...

Thanks,
Yuji

-----------------------------------------------------------------
(1)
2.2, The first paragraph
# If this note will be removed in future, please ignore:

Please add "some" between "the" and "definitions", i.e.
it should be
Note - the some definitions in this section ....

(2)
2.2, Second paragraph
Regarding to "(including user data and OAM)", it is required
that OAM here should be user's. Therefore, for kindly
clarification, it could be better to replace by "(including
user data and user OAM)"

The alternative to add "(details in 6.3.2)".

(3)
2,2, MEG
In the introduction MEP, it begins "A MEG..."
However, there are a number of "An(an) MEG" in this draft.

(4)
3.2, 3rd paragraph and 4th line.
"FM" and "PM" should be described as fault management and
peformance monitoring respectively (or add terminologies
in 2.1)

(5)
4.4 MPLS-TP PME
This subsection should be before 4.3 (LPSTME) and renumber
in align with 5 bullets ("o") at the beginning of section 4.

(6)
5.6 Client Failure Indication
This should be put after 5.7 DM, just because LM (5.5) and DM
should be put closer as part of PM.

-----------------------------------------------------------------