: MPLS Interface ping problem

Hi all,

I am using channelize link in our MPLS network. i am not able to ping my end 
IP from any of router resver or my PC.If we are pinging 10.203.50.21 getting 
packet loss.I have checked for routing at customer end too. Example as 
below:

Tracing the route to 10.203.50.21

  1 20.5.107.222 [MPLS: Labels 81/194 Exp 0] 232 msec 200 msec 196 msec
  2 20.5.107.158 [MPLS: Labels 60/194 Exp 0] 212 msec 200 msec 200 msec
  3 10.203.50.21 [MPLS: Label 194 Exp 0] 76 msec 72 msec 68 msec
  4  *  *  *

quick respose awaited.

_________________________________________________________________
Tickle your funny bone with Rahul Phondke 
http://content.msn.co.in/Lifestyle/Moreonlifestyle/LifestyleFB_101106_1455.htm

Protocol Action: 'Extensions to RSVP-TE for Point-to-Multipoint TE LSPs' to Proposed Standard

The IESG has approved the following document:

- 'Extensions to RSVP-TE for Point-to-Multipoint TE LSPs '
   <draft-ietf-mpls-rsvp-te-p2mp-07.txt> as a Proposed Standard

This document is the product of the Multiprotocol Label Switching Working

Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-07.txt

Technical Summary

  This document describes extensions to Resource Reservation 
  Protocol - Traffic Engineering (RSVP-TE) for the set up of
  Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched
  Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and 
  Generalized MPLS (GMPLS) networks.  The solution relies on RSVP-TE 
  without requiring a multicast routing protocol in the Service
  Provider core. Protocol elements and procedures for this solution
  are described.

  There can be various applications for P2MP TE LSPs such as IP
  multicast and multicast over VPNs.  Specification of how such
  applications will use a P2MP TE LSP is outside the scope of this
  document.

I-D ACTION:draft-ietf-mpls-icmp-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: ICMP Extensions for MultiProtocol Label Switching
	Author(s)	: R. Bonica, et al.
	Filename	: draft-ietf-mpls-icmp-08.txt
	Pages		: 9
	Date		: 2007-2-1
	
This memo defines an extension object that can be appended to
   selected multi-part ICMP messages.  This extension permits Label
   Switching Routers to append MPLS information to ICMP messages, and
   has already been widely deployed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mpls-icmp-08.txt".

A list of Internet-Drafts directories can be found in

draft-ietf-mpls-icmp-08.txt

This draft explains what to do if you have
IP over MPLS, but not what to do if you
are carrying something other than IP - for
example a pseudowire.

It occurs to me that in some cases it would
be useful to resolve the MPLS destination
label to the destination IP address, and
send the diagnostic packet forward.

Clearly that does not work if you have
an unknown label or an unknown next hop,
but there may be other circumstances where it
is useful.

- Stewart

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Re: draft-ietf-mpls-icmp-08.txt

Hi Stewart,

As currently defined, the ICMP message is a response to the unroutable
IP datagram. In an application like pseudowires, you wouldn't send an
ICMP packet.

However, now that ICMP messages are extensible, people might find new
applications form them. But let's say that this is beyond the scope of
this draft and fair game for future drafts.

                                     Ron

Stewart Bryant wrote:
> This draft explains what to do if you have
> IP over MPLS, but not what to do if you
> are carrying something other than IP - for
> example a pseudowire.
> 
> It occurs to me that in some cases it would
> be useful to resolve the MPLS destination
> label to the destination IP address, and
> send the diagnostic packet forward.
> 
> Clearly that does not work if you have
> an unknown label or an unknown next hop,
> but there may be other circumstances where it
> is useful.
> 
> - Stewart
> 

I-D ACTION:draft-ietf-mpls-p2mp-te-mib-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Point-to-Multipoint Multiprotocol Label 
                          Switching (MPLS) Traffic Engineering (TE) 
                          Management Information Base (MIB) module
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-mpls-p2mp-te-mib-02.txt
	Pages		: 48
	Date		: 2007-2-7
	
This memo defines a portion of the Management Information Base
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for point-to-multipoint
   Multiprotocol Label Switching-based traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-te-mib-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mpls-p2mp-te-mib-02.txt".

Recall: MPLS and VoTDM

Aline Flore Jounewe [ MTNCameroon Infrastructure Planning - MTN  would like to recall the message, "MPLS
and VoTDM".

NOTE: This e-mail message is subject to the MTN Cameroon disclaimer, see
http://www.mtncameroon.net/disclaimer.html 

NOTE: This e-mail message is subject to the MTN Cameroon disclaimer, see
http://www.mtncameroon.net/disclaimer.html 

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

MPLS and VoTDM

Can one envisage MPLS as a solution for capacity optimization?

Use ATM over MPLS to address that problem is a best solution or a
problem?

Regards;

Aline Flore Jounewe

NOTE: This e-mail message is subject to the MTN Cameroon disclaimer, see
http://www.mtncameroon.net/disclaimer.html 

NOTE: This e-mail message is subject to the MTN Cameroon disclaimer, see
http://www.mtncameroon.net/disclaimer.html 

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

MPLS and VoTDM

Can one envisage MPLS as a solution for capacity optimization?

Use MPLS over ATM to address that problem is a best solution or a
problem?

Regards;

Aline Flore Jounewe

NOTE: This e-mail message is subject to the MTN Cameroon disclaimer, see
http://www.mtncameroon.net/disclaimer.html 

NOTE: This e-mail message is subject to the MTN Cameroon disclaimer, see
http://www.mtncameroon.net/disclaimer.html 

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

RE: draft-ietf-mpls-icmp-08.txt

Ron/Stewart,

The real problem here is that we are not always clear about which layer
network are are talking about.  ICMP is part of the IP layer network's
(and ONLY the IP layer network's) management-plane.  When layer networks
get functionally coupled then folks are tempted to devise clever ways to
use the protocols that belong to one layer network in/by another layer
network....but this is really not a good general idea (this is
especially true if the layer networks involved belong to different
network modes).

The consequence of functionally coupling different layer networks is
almost always practically manifested as increased complexity and
increased marginal cost, ie one ends up with diseconomies of
scale....though it usually takes significant deployment to see this to
really figure-out what the real cause is (though it is my experience
most folks don't even see this anyway).

regards, Neil

> -----Original Message-----
> From: Ron Bonica [mailto:rbonica <at> juniper.net] 
> Sent: 07 February 2007 20:37
> To: Stewart Bryant
> Cc: mpls <at> lists.ietf.org; pwe3
> Subject: Re: [mpls] draft-ietf-mpls-icmp-08.txt
> 
> 
> Hi Stewart,
>