Subject: [mpls-tp] Final Last Call Comments on draft-ietf-mpls-tp-oam-framework-06

From: [email-masked]
Date: Mon, 26 Apr 2010 16:46:52 +0800

Hi Editors and All,

My comments on this draft are as follow:

1. In "section 5.3 Alarm Reporting" the second paragraph, propose to add 
text depicting the propagation of AIS message as follow:
"When a server MEP asserts signal fail" is changed to
"When a server MEP asserts signal fail or receives an alarm indication 
signal"

2. In "section 5.4 Lock Reporting" the second paragraph, 
one editorial comment:
"When a server MEP is locked or receives a lock report" is changed to 
"When a server MEP is locked or receives a locked report".
one technical comment:
"in both directions" is changed to
"in the downstream direction".

3. In "section 5.6.1 Configuration considerations", it need be noted that 
the DM OAM packet size is configurable as what has been mentioned in 
section 6.5.1.

4. In "section 6.3.1 Throughput Estimation" the third paragraph, the way 
how to implement the test should be optional:
"This test is performed by sending OAM test packets at increasing rate (up 
to the theoretical maximum)" is changed to
"This test may be performed by sending OAM test packets at increasing rate 
(up to the theoretical maximum)"
similar comment also applies to the following text in the fifth paragraph:
"For one-way test, remote MEP sink receives the OAM test packets and 
calculates the packet loss" is changed to
"For one-way test, remote MEP sink receives the OAM test packets and may 
calculates the packet loss"

5. In "section 6.3.1" the fourth paragraph, one editorial comment:
"a MEP source inserts OAM test packets with test information with 
specified throughput" is changed to
"a MEP source inserts OAM test packets with test information with 
specified rate"

6. In "section 6.3.1" the fifth paragraph, wrt the defined two-way 
throughput estimation which can only return the minimum of available 
throughput of the two directions, I'm not sure about the need from SP. 
Instead, to my understanding it's preferred to define two-way throughput 
estimation as a function which can return two individual available 
throughput of the two directioins, just as packet loss measurement.

7. In "section 6.5.1 Configuration considerations" the second paragraph, 
one editorial comment:
"it should be possible for the operator to configure of the on-demand OAM 
DM packet" is changed to
"it should be possible for the operator to configure the size of the 
on-demand OAM DM packet".

Hope above comments help.

Best Regards,
Xiao Min

---

From: Peng He <[email-masked]>
Date: Mon, 26 Apr 2010 22:25:03 -0400

David,

Just a small question regarding section 2.2, the definition of 'data
plane loopback': is this 'data plane loopback' functionality
started/initiated by a remote peer via OAM packets or is it started
locally by CLI? if it is the former, then ' ... such that all traffic
(including user data and OAM) ...' may not be accurate, as some
special OAM packets might be used to inform the node to stop the
loopback state.

Sounds like this 'data plane loopback' is similar to 802.3ah loopback
and 'OAM loopback' is similar to CFM loopback ..

Regards,
Peng

On Mon, Apr 26, 2010 at 4:46 AM,  <[email-masked]> wrote:
> the DM OAM packet size is configurable as what has been mentioned in section
> 6.5.1.
>
> 4. In "section 6.3.1 Throughput Estimation" the third paragraph, the way how
> to implement the test should be optional:
> "a MEP source inserts OAM test packets with test information with specified
> throughput" is changed to
> "a MEP source inserts OAM test packets with test information with specified
> rate"
>
> 7. In "section 6.5.1 Configuration considerations" the second paragraph, one
> editorial comment:
> "it should be possible for the operator to configure of the on-demand OAM DM
> packet" is changed to
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>

---

From: David Allan I <[email-masked]>
Date: Tue, 27 Apr 2010 07:51:05 -0400

Hi Peng,

Good catch, we'll update the document accordingly..

D 

-----Original Message-----
From: Peng He [mailto:[email-masked]] 
Sent: Monday, April 26, 2010 10:25 PM
To: [email-masked]
Cc: David Allan I; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Final Last Call Comments on draft-ietf-mpls-tp-oam-framework-06

David,

Just a small question regarding section 2.2, the definition of 'data plane loopback': is this 'data plane loopback' functionality started/initiated by a remote peer via OAM packets or is it started locally by CLI? if it is the former, then ' ... such that all traffic (including user data and OAM) ...' may not be accurate, as some special OAM packets might be used to inform the node to stop the loopback state.

Sounds like this 'data plane loopback' is similar to 802.3ah loopback and 'OAM loopback' is similar to CFM loopback ..

Regards,
Peng

On Mon, Apr 26, 2010 at 4:46 AM,  <[email-masked]> wrote:
> 1. In "section 5.3 Alarm Reporting" the second paragraph, propose to 
> add text depicting the propagation of AIS message as follow:
> "When a server MEP asserts signal fail" is changed to "When a server 
> MEP asserts signal fail or receives an alarm indication signal"
>
> 2. In "section 5.4 Lock Reporting" the second paragraph, one editorial 
> comment:
> 3. In "section 5.6.1 Configuration considerations", it need be noted 
> that the DM OAM packet size is configurable as what has been mentioned 
> in section 6.5.1.
>
> 4. In "section 6.3.1 Throughput Estimation" the third paragraph, the 
> way how to implement the test should be optional:
> "This test is performed by sending OAM test packets at increasing rate 
> (up to the theoretical maximum)" is changed to "This test may be 
> performed by sending OAM test packets at increasing rate (up to the 
> theoretical maximum)"
> calculates the packet loss" is changed to "For one-way test, remote 
> MEP sink receives the OAM test packets and may calculates the packet 
> loss"
>
> specified throughput" is changed to "a MEP source inserts OAM test 
> packets with test information with specified rate"
>
> Instead, to my understanding it's preferred to define two-way 
> throughput estimation as a function which can return two individual 
> available throughput of the two directioins, just as packet loss measurement.
>
> 7. In "section 6.5.1 Configuration considerations" the second 
> paragraph, one editorial comment:
> "it should be possible for the operator to configure of the on-demand 
> OAM DM packet" is changed to "it should be possible for the operator 
> to configure the size of the on-demand OAM DM packet".
>