Subject: [mpls-tp] A couple of comments on draft-frost-mpls-tp-loss-delay-01

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 22 Jul 2010 15:21:18 +0300

Dan, Stewart and all,
My colleagues and I  have a couple of comments on draft-frost-mpls-tp-loss-delay-01.

1.      The draft refers to RFC 2680<http://www.ietf.org/rfc/rfc2680.txt> for the definition of packet loss. At the same time it mentions that alternative LM techniques based on sustained insertion of test packets ... are out of scope. It is probably worth mentioning that 2680 actually defines these techniques.

2.      The draft discusses Loss Measurement (LM) and Delay Measurement (DM) for LSPs, PWs and Sections regardless of the possibility that each of these entities carries multiple traffic classes (TC).

a.      I think that this issue has been already raised on this list. I can only add that while some participants argue that a single LSP or PW in a transport network should be restricted to a single TC, it seems pretty obvious that this assumption definitely does not hold for Sections (at least for Sections that are represented by physical data links)

b.      The MPLS-TP OAM Framework draft<http://tools.ietf.org/pdf/draft-ietf-mpls-tp-oam-framework-07.pdf> seems to refer to this issue when it mentions the measured PHB Scheduling class.

c.       The draft discusses, very briefly, the case when user packets and LM ones are re-ordered between them. This case would be an exception within a given TC (and the draft effectively suggests to treat it as such). But if LM is performed across multiple TCs

3.      In order to make LM and DM TC-aware, the draft would require a few minor fixes:

a.      Explain (in the intro?) that these measurements are TC-aware

b.      Explain that the counters A_TxP/A_RxP, B_TxP, B_RxP (defined in  Section 2) are actually per TC, and use some appropriate notation (e.g., A_TxP(TC) etc.). There are no more than 8 TCs along a given MPLS-TP entity, so 16 (instead of 2) counters are required

c.       Specify that the TC (former EXP) bits in the top label of the LM and DM packets must be set to the value representing TC for which the corresponding measurement is performed

d.      Provide for encoding the specific TC in the Querier Context field. This encoding:

                                                              i.       Is desired because mapping of TC to the TC-bits value could change along the LSP

                                                            ii.      Must be coordinated between the end points of the entity for which LM and DM are performed, but the actual method of coordination could be out of scope of the draft

                                                          iii.      Trivial default encoding (for the case when the mapping between TC and TC-bits remains unchanged along the LSP) can be explicitly defined.

4.      The draft does not say whether A-TxP/A_RxP  count both the user traffic and OAM packets, or just the user traffic.

a.      The former option would:

                                                              i.      Be easy to implement

                                                            ii.      Provide for LM even in the absence of user traffic

                                                          iii.      Could also be used as the alternative LM technique, since LM packets carry sequence numbers).

b.       The latter option would be much more difficult to implement. Its benefits (if any) are not clear, but it is compatible with ITU-T Y.1731.
Hopefully these notes would be useful.

Regards,
     Sasha

Regards,
     Sasha

---

From: Dan Frost <[email-masked]>
Date: Thu, 22 Jul 2010 13:31:01 +0100

Hi Sasha,

Alexander Vainshtein <[email-masked]> writes:
> My colleagues and I have a couple of comments on
> draft-frost-mpls-tp-loss-delay-01. [...]

Many thanks for your review.  The current version of the draft is -02,
however, and there are significant differences here relative to -01 on
the topics you're commenting on.  Can you update your comments
accordingly?

Cheers,

-d

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 22 Jul 2010 15:39:57 +0300

Dan,
Lots of thanks for pointing to a newer version. I have not noticed it before, because
(a) The previous version did not even approach its expiration date 
(b) The posted MPLS WG agenda does not contain references to versions of the drafts.

I will read the new version and update my comments accordingly.

Regards,
     Sasha

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: Thursday, July 22, 2010 3:31 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Alexander Kugel; Mishael Wexler; Andrew Sergeev
Subject: Re: A couple of comments on draft-frost-mpls-tp-loss-delay-01

Hi Sasha,

Cheers,

-d

---

From: Loa Andersson <[email-masked]>
Date: Thu, 22 Jul 2010 14:48:16 +0200

Sasha,

I made the same type of mistake (picking an older version for
review).

One of the ideas on giving the filename without the version number
is that if you search bu the ID track without version number the
tracker automatically picks the latetest version.

/Loa

On 2010-07-22 14:39, Alexander Vainshtein wrote:
> Alexander Vainshtein<[email-masked]>  writes:
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

-- 

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: Alexander Vainshtein <[email-masked]>
Date: Thu, 22 Jul 2010 15:54:48 +0300

Loa,
I have been searching the drafts in Google, and it does not always bring you to the latest version.
It is probably a matter of personal preferences. But, IMO, providing the draft versions after
the cut-off date for submission is safer for the participants (but probably requires more effort from the WG Chairs;-).

Regards,
     Sasha

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, July 22, 2010 3:48 PM
To: Alexander Vainshtein
Cc: Dan Frost; Alexander Kugel; Andrew Sergeev; [email-masked]; Mishael Wexler; [email-masked]
Subject: Re: [mpls-tp] A couple of comments on draft-frost-mpls-tp-loss-delay-01

Sasha,

/Loa

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 22 Jul 2010 16:04:42 +0300

Dan, and all,
I've looked up the -02 version of the draft. Please see below my updated comments (updates are in green italics)

1.      The draft refers to RFC 2680<http://www.ietf.org/rfc/rfc2680.txt> for the definition of packet loss. At the same time it mentions that alternative LM techniques based on sustained insertion of test packets ... are out of scope. It is probably worth mentioning that 2680 actually defines these techniques. - Still valid for -02 version
2.      The draft discusses Loss Measurement (LM) and Delay Measurement (DM) for LSPs, PWs and Sections regardless of the possibility that each of these entities carries multiple traffic classes (TC).  - Addressed in the -02 version. However, I am not sure if the requirement to measure  loss per TC is only a SHOULD. IMO it is a MUST at least for Sections. I have removed the related sub-items.
3.      In order to make LM and DM TC-aware, the draft would require a few minor fixes:
a.      Explain (in the intro?) that these measurements are TC-aware - Still valid for -02 version
b.      Explain that the counters A_TxP/A_RxP, B_TxP, B_RxP (defined in  Section 2) are actually per TC, and use some appropriate notation (e.g., A_TxP(TC) etc.). There are no more than 8 TCs along a given MPLS-TP entity, so 16 (instead of 2) counters are required - Still valid for -02 version
c.      Specify that the TC (former EXP) bits in the top label of the LM and DM packets must be set to the value representing TC for which the corresponding measurement is performed - Still valid for -02 version
d.      Provide for encoding the specific TC in the Querier Context field. - Still valid for -02 version
4.      The draft does not say whether A-TxP/A_RxP  count both the user traffic and OAM packets, or just the user traffic. - Still valid for -02 version

Regards,
     Sasha

-----Original Message-----
From: Dan Frost [mailto:[email-masked]]
Sent: Thursday, July 22, 2010 3:31 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Alexander Kugel; Mishael Wexler; Andrew Sergeev
Subject: Re: A couple of comments on draft-frost-mpls-tp-loss-delay-01

Hi Sasha,

Cheers,

-d

---

From: Dan Frost <[email-masked]>
Date: Thu, 22 Jul 2010 14:48:19 +0100

Hi Sasha,

Alexander Vainshtein <[email-masked]> writes:
> 1.  The draft refers to RFC 2680<http://www.ietf.org/rfc/rfc2680.txt>
> for the definition of packet loss. At the same time it mentions that
> alternative LM techniques based on sustained insertion of test packets
> ... are out of scope. It is probably worth mentioning that 2680
> actually defines these techniques. - Still valid for -02 version

Thanks for the comment.  We are in the process of looking at
soft-counter approaches, including RFC 2680, and will be updating the
draft text accordingly.

> 2.  The draft discusses Loss Measurement (LM) and Delay Measurement
> (DM) for LSPs, PWs and Sections regardless of the possibility that
> each of these entities carries multiple traffic classes (TC).  -
> Addressed in the -02 version. However, I am not sure if the
> requirement to measure loss per TC is only a SHOULD. IMO it is a MUST
> at least for Sections. I have removed the related sub-items.

Fair comment.  It would be good to hear more from the WG on requirements
levels for per-class measurement.

> Still valid for -02 version

This is currently noted in the last paragraph of Section 2 (Overview).

> b.  Explain that the counters A_TxP/A_RxP, B_TxP, B_RxP (defined in
> Section 2) are actually per TC, and use some appropriate notation
> (e.g., A_TxP(TC) etc.). There are no more than 8 TCs along a given
> MPLS-TP entity, so 16 (instead of 2) counters are required - Still
> valid for -02 version

I am not sure that with the note in Section 2 and the text in Section 5
that a change of notation is necessary.  Mixing TCs into the measurement
method sections only makes them harder to read, in my opinion.

> c.  Specify that the TC (former EXP) bits in the top label of the LM
> and DM packets must be set to the value representing TC for which the
> corresponding measurement is performed - Still valid for -02 version

Yes, we will be more explicit about marking in Section 5.1.

> field. - Still valid for -02 version

Yes, we are currently looking at options for including TC information.

> 4.  The draft does not say whether A-TxP/A_RxP count both the user
> traffic and OAM packets, or just the user traffic. - Still valid for
> -02 version

This is Section 5.2.  We will, however, probably reverse the logic here,
i.e. instead say "by default MUST exclude" and "MAY include", because of
the possibility of intermediate nodes generating G-ACh messages.

Thanks for the review!

-d

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 22 Jul 2010 16:51:55 +0300

Dan,
Lots of thanks for a prompt response. Looks like we are on the same wavelength. 
And I agree with you regarding ambiguity of notation vs. readability: these two do not always go together.

Regards,
     Sasha

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: Thursday, July 22, 2010 4:48 PM
To: Alexander Vainshtein
Cc: Stewart Bryant; [email-masked]; Alexander Kugel; Mishael Wexler; Andrew Sergeev
Subject: Re: A couple of comments on draft-frost-mpls-tp-loss-delay-01 - now for the -02 version

Hi Sasha,

Thanks for the review!

-d

---

From: "t.petch" <[email-masked]>
Date: Fri, 30 Jul 2010 10:20:53 +0200

----- Original Message -----
From: "Alexander Vainshtein" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Sent: Thursday, July 22, 2010 2:54 PM

> I have been searching the drafts in Google, and it does not always bring you
to the latest version.

I always use www.watersprings.org which is doubtless not quite up to date but I
have never been caught out by the difference.

And its interface is so much easier to use than the high tech one we now have
with the IETF website that .... well I am off to it again just now.

Tom Petch
> the cut-off date for submission is safer for the participants (but probably
requires more effort from the WG Chairs;-).

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 30 Jul 2010 23:12:07 +0200

tools.ietf.org makes it very easy to get to the latest revision,
without knowing the revision numbers.

For example, check out
http://tools.ietf.org/html/draft-frost-mpls-tp-loss-delay .

You can also get the diffs between revisions.

Cheers,
Andy