Subject: [mpls-tp] WG Last call on draft-ietf-mpls-tp-oam-framework-08.txt

From: Loa Andersson <[email-masked]>
Date: Fri, 17 Sep 2010 18:46:27 +0200

All,

this is to start a further one week final working group last call on
draft-ietf-mpls-tp-oam-framework-08.txt

The document has been updated to address the comments received during 
the previous last call

Please note that the purpose of this working group last call is
only to verify that comments from the previous working group last call 
have been correctly addressed.

The authors have been instructed to post a note to the mailing list
outlining what comments were raised and how they have addressed them.

Please note that even though the document is Informational and not
implementable per se we have a very late IPR disclosure (arrived after
the previous wg last call):

https://datatracker.ietf.org/ipr/1369/

The terms cited are RAND and do not include the mutual free terms seen
in other IPR disclosures.

It might be that in cases where the framework indicates the use of
a particular technology, then any solutions document conforming to
the framework would be at risk from the IPR.

Please send your comments to the [email-masked] mailing list.

This working group last call ends Sep 28th.

Loa and George

-- 

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

---

From: Yuji Tochio <[email-masked]>
Date: Tue, 28 Sep 2010 16:17:21 +0900

Hi

Some comments on sec 5.1.1.4 that is new since version 08.

1) First sentense:
If pro-active CC-V OAM packets are received with a correct globally
unique Source MEP identifier but with an encapsulation,

Should this be as following?
... but with an *unexpected* encapsulation,

2) If a different encapsulation of period field is detected,
isn't section 5.1.1.3 applied?
I.e. It should be described the detect in 5.1.1.3 must
be prioir to this 5.1.1.4.

3) What kind of defect is this for if detected?
Is this a new or another version of dLOC? or same as it?

4)
I cannot understand the paragraph of "It should be noted that..."
The essense, I think, of this section is that this defect does not
impact on misconnectivity, but different encapsulation from
that as configured.
So It should be that the essense I wrote above put at the
first of this section, i.e. some text in this paragraph should be
put at the first of this section

... And if editors are worring about OAM frames are gone before
processing, this warning notes should be put at the 5.1.1.1 since
this is the matter of LOC rather than this section.

5)
What would be the consequent action for this?
Is this expected to block the traffic?
(Overall, the description of consequent actions for defect in
5.1 seems to be lack...)

Regards,
Yuji

---

From: David Allan I <[email-masked]>
Date: Tue, 28 Sep 2010 07:08:24 -0400

Hello Yuji:

When originally put into the document, the primary scenario of interest was a PW (GACH only) leaking into an LSP (GAL/GACH) or vice versa, which was clearly a misconnectivity defect. And needing to fully parse to identify all possible encapsulations in real time in order to specifically identify merely bad encap configuration from true mis-connectivity seemed excessivly complicated to demand of an implementation vs. simply logging the PDU for off line processing and calling everything "mis-connectivity".

At least that was my thinking. You got it right at provisioning time, and if strange OAM PDUs started appearing mid-lifetime, shut it down....

Most of the feedback we've gotten suggests that our making all unexpected-encap scenarios into the eqivalent of mis-connectivity is considered too draconian and folks actually want to parse everything they receive. And if the unexpected encap contains a correct MEP, let it off with a warning.... Hence only consequent action is an indication to EMS/NMS of a minor problem.

That background being said, we'll review your comments accordingly. And the answer to some of your questions I hope leaps out in the discussion above...

Cheers
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yuji Tochio
Sent: Tuesday, September 28, 2010 3:17 AM
To: [email-masked]
Subject: Re: [mpls-tp] WG Last call on draft-ietf-mpls-tp-oam-framework-08.txt

Hi

1) First sentense:
If pro-active CC-V OAM packets are received with a correct globally unique Source MEP identifier but with an encapsulation,

2) If a different encapsulation of period field is detected, isn't section 5.1.1.3 applied?
I.e. It should be described the detect in 5.1.1.3 must be prioir to this 5.1.1.4.

4)
I cannot understand the paragraph of "It should be noted that..."
The essense, I think, of this section is that this defect does not impact on misconnectivity, but different encapsulation from that as configured.
So It should be that the essense I wrote above put at the first of this section, i.e. some text in this paragraph should be put at the first of this section

... And if editors are worring about OAM frames are gone before processing, this warning notes should be put at the 5.1.1.1 since this is the matter of LOC rather than this section.

5)

Regards,
Yuji

Loa Andersson wrote:
> Please note that the purpose of this working group last call is only 
> to verify that comments from the previous working group last call have 
> been correctly addressed.
>
> It might be that in cases where the framework indicates the use of a 
> particular technology, then any solutions document conforming to the 
> framework would be at risk from the IPR.
>

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

---

From: Yoshinori KOIKE <[email-masked]>
Date: Wed, 29 Sep 2010 06:02:09 +0900

Hello Dave and Italo,

Followings are my comments on oam-framework-08.
All the comments except for [1] are not the comments
to verify that comments from the previous working
group last call have been correctly addressed.
Therefore, those comments might be informational
and not effective. However, I prepared
all the proposed texts to make the process
effective as much as possible when they are taken
into consideration to enhance the draft.

[1] 3. Functional components

"Monitoring" function in current transport networks is based
on the following two network objectives shown in LS210.

(1) The monitoring and maintenance of existing transport paths has to be
conducted in service without traffic disruption.
(2) The monitored or managed transport path condition has to be exactly
the same irrespective of any configurations necessary for maintenance.

Even in MPLS-TP network(Packet transport network), these network
objectives are indispensable for a powerful and efficient
maintenance capability.

Therefore, I suggest the following texts as new section 3.8

(Proposed texts)
3.8 Further considerations of enhanced segment monitoring

Transport network should meet the following network objectives.
(1) The monitoring and maintenance of existing transport paths has to be
conducted in service without traffic disruption.
(2) The monitored or managed transport path condition has to be exactly
the same irrespective of any configurations necessary for maintenance.

SPMEs of section 3.2 might be able to meet the above two objectives,
if they are pre-configured or pre-instantiated as exemplified in
section 3.6. However, pre-design and pre-configuration of all the
considered patterns of SPME are not sometimes preferable in real
operation due to the burden of design works, a number of header 
consumptions, bandwidth consumption and so on.

On the other hand, if SPMEs are configured or instantiated after
the transport path is in-service. Network objetive (1) can be met,
but Network objective (2) cannot be met due to new assignment of
tunnel label.

Considering these circumstances, more sophisticated segment monitoring
mechanism(temporal and hitless segment monitoring) to efficiently meet
the two network objectives is necessary. This new solution should be 
specified in other document.
(end of proposed text)

[2] 6.3.1. Throughput Estimation
According to RFC5860, Diagnostic tests function
SHOULD be performed between End Points and Intermediate
Points and between End Points. On the other hand, the
support of the throughput estimation between MEP and MIP
is not supported in section 6.3.1 of OAM FWK-08.
There seems an inconsistency. Need to align with the
requirement in RFC5860 (or modify RFC5860). The proposed
texts are as follows.

(Current texts 1)
This function SHOULD be performed between End Points and Intermediate
Points of PWs and LSPs, and between End Points of PWs, LSPs, and
Sections.

(Proposed texts 1)
Throughput estimation is performed between MEPs and between
MEP and MIP. It can be performed in one-way or two-way modes.

(Current texts 2)
MIPs, as well as intermediate nodes, do not process the throughput
test information and forward these on-demand test OAM packets as
regular data packets.

(Proposed tests 2)
MIPs, as well as intermediate nodes, can also process the throughput
test information just like MEP.

[3]6.3.2 Data plane Loopback
The first sentence is not clear. Particularly, the difference
between "originated at the ingress of a transport path" and
"inserted by the test equipment" is not clear. In addition,
some notes to differentiate data-plane loopback point and
MIP/MEP seem helpful for readers.

(Proposed modified texts)
Data plane loopback is an out-of-service function, as required
in section 2.2.5 of RFC 5860 [11]. This function permits all
traffic(including user data and OAM, with the exception of the
disable loopback command). The traffic is originated from
one internal point at the ingress of a transport path within a
interface or inserted from input port of an interface by the
external test equipment to be looped back unmodified (other than
normal per hop processing such as TTL decrement). All the traffic
are loop backed in the direction of the point of origin by an
interface at either an intermediate node or a terminating node.

It should be noted that data plane loopback function itself is
applied between data-plane loopback points within interfaces
which is different from MIP/MEP.
(end of proposed texts)

[4] 6.3.2 Data plane loopback
There seems no description about configuration consideration.
Need to add general description.

(Proposed texts)
6.3.2.1. Configuration considerations

Data plane loopback is an out-of-service tool. The MEG which
defines a diagnosed transport path which should be put into
a Lock status before the diagnostic test is started. However,
the originated traffic or inserted traffic must be admitted
to go through ingress MEP when data plane loopback is performed.

A data plane loopback point of a transport path can be put into
data plane loopback status via an NMS action or using Loopback
OAM tool. In addition, a MEG which define the transport path
can be put into a Lock status either via an NMS action or using
the Lock Instruct OAM tool as defined in section 7.

If the data plane loopback point is set somewhere at intermediate
point in bidirectional transport path, the side of loop back
function(one side or both side) needs to be configured.
(end of proposed texts)

Best regards,

Yoshinori

-- 
**************************************
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: Wed, 29 Sep 2010 17:02:46 +0200

All,

this wg last call has ended!

Could the editors please evaluate and address comments as appropriate.

/Loa

--