The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Apr> msg00054



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt

  • From: <benjamin.niven-jenkins@bt.com>
  • Date: Thu, 13 Apr 2006 11:44:21 +0100
  • Thread-Index: AcZeandujIY3UM6LSmuXKVMLE1tAcgAe42Og
  • Thread-Topic: [mpls] I-D ACTION:draft-ietf-mpls-p2mp-lsp-ping-01.txt
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id k3DAjuH10257
  • X-OriginalArrivalTime: 13 Apr 2006 10:44:23.0082 (UTC)FILETIME=[3A09E0A0:01C65EE7]

Colleagues,

I have a couple of comments on this draft.

1) Why is it restricted to P2MP TE LSPs?  mLDP signalled LSPs will also
require OAM and it's not clear to me why they have been precluded by
this draft.

2) Section 4.1 of draft-ietf-mpls-p2mp-oam-reqs-01 states "The ability
to detect defects in a P2MP LSP SHOULD not require manual, hop-by-hop
troubleshooting of each LSR used to switch traffic for that LSP, and
SHOULD rely on proactive OAM procedures (such as continuous path
connectivity and SLA measurement mechanisms)." whereas the comments in
draft-ietf-mpls-p2mp-lsp-ping-01 imply to me that proactive/continuous
OAM may not be possible with the proposed solution due to scaling
concerns resulting from the possibility of flooding the ingress with
responses.  As well as the ability to delay/jitter the echo responses
has consideration been given to other potential ways to improve
scalabilty for example using a Nack model for responses, somehow
aggregating responses etc.?

Thanks
Ben

-- 
Ben Niven-Jenkins
Network Architect, BT Exact
  
E-mail: benjamin.niven-jenkins@bt.com 
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls