Subject: [pm-dir] Fwd: [mpls] MPLS test session protocol

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 3 Dec 2012 02:20:31 +0000

FYI -- see http://tools.ietf.org/html/draft-frost-mpls-test-session-00 in support of http://tools.ietf.org/html/rfc6374

Thanks,

-- Carlos.

Begin forwarded message:

From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] MPLS test session protocol
Date: November 27, 2012 8:42:34 AM EST
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Reply-To: [email-masked]<mailto:[email-masked]>

MPLS Working group,

The authors of draft-frost-mpls-test-session-00 wrote this draft to
provide a simple and general G-ACh protocol for the setup and control of
test traffic streams over MPLS.  Such test streams are required by the
Inferred Loss Measurement (ILM) mode specified in RFC 6374, and are
useful for other purposes.

This draft was presented at IETF 85 and received two comments, from Lou
Berger and Greg Mirsky.  The authors would like to request feedback from
other WG members as to whether this draft should progress in the MPLS
WG.

To summarize the brief IETF 85 discussion, Greg felt the work was
important but proposed using RSVP-TE/LDP for test session signaling.
Lou similarly felt that RSVP-TE should be used in IP environments and
that static NMS control is sufficient for non-IP MPLS-TP networks.

Note that to support Pseudowire we would also need to define and implement an LDP signalling solution in addition to the RSVP-TE
solution proposed by Lou. Further note that an LDP only solution
is not an option in MPLS-TP because G-MPLS is the only control
plane available for LSPs.

In the view of the authors, it is important to have good protocol tools
available to support OAM applications over the G-ACh in MPLS-TP networks
with elements that do not necessarily support an IP stack.  We do not
find it convincing that a strictly NMS-based static configuration
approach suffices to meet the needs of all such deployments.

Also, in our view, even some IP network operators may be reluctant to
deploy RSVP-TE between, for example, two adjacent nodes merely to get a
packet loss measurement for a connecting link.

We'd like to hear your views.  Do you think the protocol described in
the draft is a useful addition to the MPLS toolset?

- Stewart & Dan (draft authors)

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