Nurit Sprecher | 3 Aug 2003 13:10

Support of Graceful Restart for RSVP-TE

Hi all,

Is there any standard/draft describing the procedure to graceful restart of RSVP-TE in order to minimize the negative effects on MPLS traffic caused by LSR's control plane restart?

I can see that there was such a draft written by Pan. What is the status of the draft? Expired? Any progression with it?

Thanks in advance, Nurit.

RE: Support of Graceful Restart for RSVP-TE

See RFC 3473 section 9
 
JL
-----Message d'origine-----
De : Nurit Sprecher [mailto:nurit.sprecher <at> SeabridgeNetworks.com]
Envoyé : dimanche 3 août 2003 13:10
À : 'ccamp <at> ops.ietf.org'; 'mpls <at> uu.net'
Cc : Nurit Sprecher
Objet : Support of Graceful Restart for RSVP-TE

Hi all,

Is there any standard/draft describing the procedure to graceful restart of RSVP-TE in order to minimize the negative effects on MPLS traffic caused by LSR's control plane restart?

I can see that there was such a draft written by Pan. What is the status of the draft? Expired? Any progression with it?

Thanks in advance, Nurit.

Michael Mandelberg | 5 Aug 2003 00:22

Another Question re: P/NHOP in GMPLS

According to rfc 3473:
 

A node that receives an IF_ID object SHOULD

   check whether the information carried in this object is consistent

   with the information carried in a received ERO, and if not it MUST

   send a PathErr Message with the error code "Routing Error" and error

   value of "Bad Explicit Route Object" toward the sender.  This check

   CANNOT be performed when the initial ERO subobject is not the

   incoming interface.

 

However, an LSR receiving a path message with an ero processes it as follows: if the LSR is a part of the node specified by the first subobject, it selects a hop, then *removes* that subobject. In other words, the ERO does not contain information about the route to get to that LSR, this information is in the RRO.

 

This may be a minor point, but I want to make sure that I understand it properly. Shouldn't the text above say:

 

 

A node that receives an IF_ID object SHOULD

   check whether the information carried in this object is consistent

   with the information carried in a received **RRO**, and if not it MUST

   send a PathErr Message with the error code "Routing Error" and error

   value of "Bad Explicit Route Object" toward the sender.  This check

   CANNOT be performed when the initial **RRO** subobject is not the

   incoming interface.

 

Am I mistaken? If so, why?

 

Thanks

 

Michael Mandelberg

Michael Mandelberg | 4 Aug 2003 23:30

Question re: P/NHOP field for unnumbered interfaces in GMPLS

According to rfc 3473:
 

The Hop Address and Logical Interface Handle fields are  used per standard RSVP [RFC2205].

 

According to rfc 2205:

 

This object carries the IP address of the interface through which the last RSVP-knowledgeable hop forwarded this message. 

 

But in the case of unnumbered interfaces, there is no such address. What should go in this field? A router ID?

 

Thanks

 

Michael Mandelberg

 

Internet-Drafts | 6 Aug 2003 16:40
Picon
Favicon

I-D ACTION:draft-ietf-mpls-ftn-mib-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		: Multiprotocol Label Switching (MPLS) Forwarding 
                          Equivalence Class To Next Hop Label Forwarding Entry 
                          (FEC-To-NHLFE)Management Information Base
	Author(s)	: T. Nadeau, C. Srinivasan, A. Viswanathan
	Filename	: draft-ietf-mpls-ftn-mib-08.txt
	Pages		: 40
	Date		: 2003-8-6
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for defining, configuring
and monitoring Forwarding Equivalent Class (FEC) to Next Hop Label
Forwarding Entry (NHLFE) mappings and corresponding actions for use
with Multiprotocol Label Switching (MPLS).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ftn-mib-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ftn-mib-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 135 bytes
Attachment (draft-ietf-mpls-ftn-mib-08.txt): message/external-body, 67 bytes
Carlos Becker Westphall | 6 Aug 2003 15:23
Picon

NOMS 2004 - Nine days to the Deadline - 15th August 2003

***** Paper submission deadline extended to Friday 15th August 2003 *****

        Network Operation & Management Symposium 2004 

"Managing Next Generation Convergence Networks and Services"

                Seoul Korea, 19-23, April 2004

See < http://www.noms2004.org/> for latest information

The 9th IEEE/IFIP Network Operations and Management Symposium (NOMS 2004)
will be held 19-23 April, 2004 at Seoul, Korea. Held in the even-numbered
years since 1988, NOMS 2004 will continue the established tradition of
NOMS and IM as the primary forum for technical exchange of research,
standards, development, systems integrator, service providers, and user
communities. NOMS 2004 will present the latest approaches and technical
solutions in the area of network operations and management. An exciting,
peer-reviewed program of technical sessions, tutorials, posters, panels
and vendor exhibits will address the ever-increasing interest in overall
management solutions for all types of communications and computing
networks, systems, services and enterprise applications.

The concept of network convergence has recently emerged as a new attempt
for the merging of telephony and data networks into a single,
multi-service network exploiting the ubiquity of the Internet Protocol.
For this increasingly attractive business model, in both wired and
wireless domains, strategic research is required to devise the best
integration architectures, operations and management solutions. This
creates a unique opportunity for the network operation and management
community to respond to the ever-increasing demand for network resilience,
security, quality-of-service and mobility management at unprecedented
scales. The NOMS 2004 provides the forum for discussing these research
challenges and many others inherent to the integrated management of next
generation converged networks and services.

This year NOMS 2004 will broaden the scope of previous IM and NOMS by
expanding its program to include a broader set of topics ranging from
network operation and management to network planning, service engineering
and business processes for network and service management. Special
attention will be given to experiences that emphasize lessons learned and
reports on practice from industry. Authors are invited to submit complete
unpublished papers, which are not under review in any other conference or
journal. Authors are also invited to submit proposals for tutorials, panel
discussions, poster demonstrations, or birds-of-a-feather sessions.

Important Dates:
Deadline  for  Submitting  Papers: 15  August   2003
Deadline  for  Tutorials, Panels and  Posters:  1 October  2003
Notification of Acceptance:15 November 2003
Deadline for Submitting Revised Papers:15 December 2003

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Michael Mandelberg | 7 Aug 2003 04:46

FW: Label Set question

How does the label set work with waveband labels? For the list form, are the subobjects waveband ids, or are the start and stop values listed as well? For the range form, again is it just ids? If not, then how is ordering defined to deterimine whether another band laebl is within the range?
 
Thanks
 
Michael Mandelberg
Naga Srinivas V | 7 Aug 2003 05:53

Re: Label Set question

I think, in rfc 3472  section 2.5.1. Procedures is explaning about the Label set procedures, will help you.
 
 
 
 
Thanks,
srinivas.
 
----- Original Message -----
Sent: Thursday, August 07, 2003 8:16 AM
Subject: FW: Label Set question

How does the label set work with waveband labels? For the list form, are the subobjects waveband ids, or are the start and stop values listed as well? For the range form, again is it just ids? If not, then how is ordering defined to deterimine whether another band laebl is within the range?
 
Thanks
 
Michael Mandelberg


***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
Cheenu Srinivasan | 7 Aug 2003 14:06
Picon
Favicon

(unknown)

Version 8 of the FTN MIB has been posted. It incorporates all the comments
received during the (latest) WG last call and A-D review.

http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-08.txt

Thanks,
Cheenu

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Anu Divya | 7 Aug 2003 16:46
Favicon

Clarification in Traffic Engineering

Below mail thread discusses regarding the Traffic Engineering 
Extension of OSPF and CSPF.

This discussion concludes that the Route selection through the 
network is performed using only the Unreserved Bandwidths for 
Class-Types.

The Maximum Reservable Aggregate Bandwidth (which can be thought 
of as the Maximum Reservable Bandwidth for Class-Type 0) is 
advertized for historical reasons, i.e. original IGP extensions 
for TE included it and we didn't want to simply remove it as our 
extensions are built on the original extensions.

If we are going to use only Unreservered bandwith (for 
class-types) during Route calculation, what is the use of Maximum 
bandwidth in CSPF. Is this TLV also retained for historical 
reasons like Maximum Reservable Bandwidth?

Question on BW advertisements for Diffserv aware TE based on Class 
Type
 From: "Sudhakar Ganti" <sganti <at> tropicnetworks.com>
Date: Wed, 16 May 2001 10:01:26 -0400
Cc: "mpls" <mpls <at> UU.NET>
Importance: Normal
In-Reply-To: <3B027840.48CAD796 <at> americasm01.nt.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)

Hi Darek,

Thanks for your reply. If the Maximum Reservable Bandwidth for 
Class Type-N
is implicitly inferred, then I think the text in both these drafts 
should not refer to this
as it is implementation / configuration specific.

Second thing is that, it may be necessary to advertise this value. 
It gives
an option for Traffic Engineering not to take paths that are 
overbooked for a
given class if necessary. We may not be able to infer this from 
Unreserved
bandwidth. If not, is there any other way to know about it? 
Thanks

-Sudhakar
-----Original Message-----
 From: owner-mpls <at> UU.NET [mailto:owner-mpls <at> UU.NET]On Behalf Of 
Darek Skalecki
Sent: Wednesday, May 16, 2001 8:53 AM
To: Sudhakar Ganti
Cc: mpls
Subject: Re: Question on BW advertisements for Diffserv aware TE 
based on Class Type

Hi Sudhakar,
See inlined answers.

Thanks,

Darek

Sudhakar Ganti wrote:

Hello,
A couple of questions regarding the BW advertisements
on these drafts:
     draft-ietf-mpls-diff-te-ext-01.txt
     draft-ietf-ospf-diff-te-00.txt

a) The text in both the drafts refers to "the Class-Type N
    bandwidth currently unreserved (i.e. the difference
    between the Maximum Reservable Bandwidth for Class-Type N
    and the bandwidth reserved by existing Class-Type N LSPs)"

However I do not see any separate sub-TLV for Max reservable
bandwidth for each class type (class type N). There is only one
that advertises the Max Reservable Aggregate Bandwidth.

The Maximum Reservable Bandwidth for Class-Type N is reflected in 
the Unreserved Bandwidth for Class-Type N. That is, there is no 
need to advertize through IGP the Maximum Reservable Bandwidth for 
Class-Type N as it is implicitely advertized  in the Unreserved 
Bandwidth for Class-Type N. The intention is that the Maximum 
Reservable Bandwidth for Class-Type N is configured on links that 
support Class-Type N. However, when it is time to advertize 
bandwidth availability for that link, only the Unreserved 
Bandwidth for Class-Type N is computed, as you stated by quoting 
the draft, and then advertized through IGP. Route selection 
through the network is then performed using only the Unreserved 
Bandwidths for Class-Types.

The Maximum Reservable Aggregate Bandwidth (which can be thought 
of as the Maximum Reservable Bandwidth for Class-Type 0) is 
advertized for historical reasons, i.e. original IGP extensions 
for TE included it and we didn't want to simply remove it as our 
extensions are built on the original extensions.

b) Different classes can be oversubscribed differently
    depending upon the link (or network) configuration.
    If so, I think it may be necessary to advertise the
    Maximum Reservable bandwidth for each Class (Class-Type N).

    Is there any reason why this is omitted??

See my answer to a). Since Maximum Reservable Bandwidth for 
Class-Type N is implicitely "included" in the Unreserved Bandwidth 
for Class-Type N and it is the Unreserved Bandwidth for Class-Type 
N that is advertized through IGPs and used for route computation, 
there is no need to separately advertize Maximum Reservable 
Bandwidth for Class-Type N. To oversubscribe a link, the sum of 
Maximum Reservable Bandwidths for all Class-Types supported by the 
link needs to be greater than the capacity of the link. As I 
already mentioned, each Maximum Reservable Bandwidth for 
Class-Type N is configured on the link and used in the computation 
of the Unreserved Bandwidth for Class-Type N for advertizing 
purposes.

-Sudhakar

--
Darek Skalecki
Nortel
(613) 765-2252

___________________________________________________
Download the hottest & happening ringtones here!
OR SMS: Top tone to 7333
Click here now: 
http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl


Gmane