Arthi Ayyangar | 1 Mar 07:32 2006
Picon

Recording AS Hops in RRO - discussion

Re-sending. Didn't see this appear on the list.

-arthi

---------- Forwarded message ----------
Date: Tue, 28 Feb 2006 00:11:11 -0800 (PST)
From: Arthi Ayyangar <arthi <at> juniper.net>
To: ccamp <at> ops.ietf.org
Subject: Recording AS Hops in RRO - discussion

Hi,

As per RFC 3209, there exists a provision to add AS number hops in ERO as 
sub-objects.

This definitely has usage in inter-AS LSPs, so a user may configure AS hops to 
direct an LSP through a specific AS path.

However, from what I have checked, currently there is no provision to record AS 
numbers in the RRO.

If this provision already exists and I missed it, do point me to it. Else, do 
you think this would be useful to have ?

We say that it would be useful to aggregate /modify RROs sent out of an AS for 
confidentiality. Would adding AS number sub-oject to RRO help ?
Would it also help in identifying loops involving LSPs traversing same AS more 
than once ?

thanks,
(Continue reading)

Picon

RE: Inter-domain FRR Facility backup - discussion

Can the ASBR help out here:
 - Can it advertise a route with itself as the next hop for the PLR into the
MPs domain whenever it sees a bypass tunnels path msg going through it ?

First of all, how is the bypass itself signalled without any issues ? The
PLR wont know the topology of the other domain to route the path msg to the
MP in a node disjoint way.

Regards,
Vijay

> -----Original Message-----
> From: owner-ccamp <at> ops.ietf.org [mailto:owner-ccamp <at> ops.ietf.org]On
> Behalf Of Arthi Ayyangar
> Sent: Tuesday, February 28, 2006 1:25 PM
> To: ccamp <at> ops.ietf.org
> Subject: Inter-domain FRR Facility backup - discussion
> 
> 
> Hi,
> 
> Currently the merging of Backup Paths using the Sender 
> Template-specific 
> method relies on a different src address, but same LSP ID in the 
> SENDER_TEMPLATE for the backup LSP compared to that of the 
> protected LSP. 
> (6.1.1 of rfc 4090). After a failure, during local repair, 
> backup LSP Path 
> msgs are "tunneled" over the bypass directly to the MP and 
> the Resv from 
(Continue reading)

Zafar Ali (zali | 2 Mar 07:06 2006
Picon

RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)

Hi Dimitri, 

Sorry for the delay in replying. Please see reply in-line. 

All, 

I am assuming the WG is ok with the signaling part of the solution. If
you have any comments, please reply to my original email. We plan to
refresh the ID before the flood gate closes. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou <at> psg.com] 
> Sent: Monday, February 20, 2006 2:01 AM
> To: Zafar Ali (zali)
> Cc: ccamp <at> ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz); 
> Jean Philippe Vasseur (jvasseur); Kireeti Kompella
> Subject: Re: Need to close on signaling solution for graceful 
> shutdown (Follow-up on our Action Item)
> 
> 
> zafar - thanks for the summary ... but i don't understand the 
> following sentence
> 
> "The IGP based solution is also based on an existing framework."
> 
> to which framework are you referring to ?
(Continue reading)

Adrian Farrel | 3 Mar 16:58 2006
Picon

New version of GMPLS LSR MIB

Hi,

I have just submitted a new revision of the GMPLS LSR MIB
(draft-ietf-ccamp-gmpls-lsr-mib-11.txt) which should be posted soon.

The changes are to complete the markups from MIB Doctor review and
comprise changes to the conformance and compliance sections of the MIB
module as requested.

We will show this to the MIB Doctors to check that they are happy with all
of our changes, and then get the IESG process into motion.

Adrian

PS. No changes to the TC MIB.
PPS. Changes to the TE MIB to be submitted soon.

Suresh Katukam (skatukam | 3 Mar 17:44 2006
Picon

Draft on 1+1..


Hi,

There was a proposal by Lucent (I believe)
about using 1+1 mechanism in data networks.

I believe they proposed that source and
destination set up two tunnels, and add seq#
to each packet in the tunnel and let the
destination decide which stream to use.

I have been searching for that draft and
could not find.

Can you please let me know where can
I find it.

Thanks,
Suresh

Adrian Farrel | 3 Mar 19:17 2006
Picon

New revision of GMPLS TE MIB

Hi,

I have just submitted a new revision of the GMPLS TE MIB
(draft-ietf-ccamp-gmpls-te-mib-13.txt) which should be posted soon.

The changes are to complete the markups from MIB Doctor review and
comprise changes to the conformance and compliance sections of the MIB
module as requested.

I have also made the following changes:
- added comments to IANAGmplsGeneralizedPid to highlight the lacunae.
- updated references to RFC 4328
- correct possible settings of mplsTunnelIsIf which is TruthValue
- retire gmplsTunnelIsNotIntfcGroup which had become empty
- correct the example to use gmplsTunnelSendPathNotifyRecipientType
  and gmplsTunnelSendPathNotifyRecipient
- correct the hex value of an IP address in the example

We will show this to the MIB Doctors to check that they are happy with all
of our changes, and then get the IESG process into motion.

Adrian

Dimitri.Papadimitriou | 4 Mar 00:45 2006
Picon
Picon

RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)

hi zafar

then i will express my concern in the other way around concerning the 
"routing" part of this document: we have clean procedures for planned node 
restart in RFC4203; hence, the reason for having a "cleaner" procedure is 
totally unclear to me both in terms of motivation and applicability

much thanks,
- dimitri.

"Zafar Ali \(zali\)" <zali <at> cisco.com>
Sent by: owner-ccamp <at> ops.ietf.org
02/03/2006 07:06

        To:     <dpapadimitriou <at> psg.com>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL <at> ALCATEL
        cc:     <ccamp <at> ops.ietf.org>, "Adrian Farrel" 
<adrian <at> olddog.co.uk>, "Anca Zamfir \(ancaz\)" <ancaz <at> cisco.com>, "Jean 
Philippe Vasseur \(jvasseur\)" <jvasseur <at> cisco.com>, "Kireeti Kompella" 
<kireeti <at> juniper.net>
        Subject:        RE: Need to close on signaling solution for 
graceful shutdown (Follow-up on our Action Item)

Hi Dimitri, 

Sorry for the delay in replying. Please see reply in-line. 

All, 

I am assuming the WG is ok with the signaling part of the solution. If
(Continue reading)

Internet-Drafts | 4 Mar 00:50 2006
Picon

I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching 
                          (GMPLS) Label Switching Router (LSR) 
                          Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-11.txt
	Pages		: 42
	Date		: 2006-3-3
	
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 to configure and/or
   monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
   Switching Router (LSR).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-11.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-ccamp-gmpls-lsr-mib-11.txt".

(Continue reading)

Internet-Drafts | 4 Mar 00:50 2006
Picon

I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching 
                          (GMPLS) Traffic Engineering Management 
                          Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-te-mib-13.txt
	Pages		: 60
	Date		: 2006-3-3
	
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 Generalized
   Multiprotocol Label Switching (GMPLS) based traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-13.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-ccamp-gmpls-te-mib-13.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Zafar Ali (zali | 5 Mar 19:02 2006
Picon

RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)

Hi Dimitri, 

There is a difference between expected operations in graceful restart
and graceful shutdown; hence my previous email. The draft already lists
Max Metric as a possible solution with motivation for selecting link
attribute based solution. If the WG agrees that use of Max Metric
suffices, we can fall back to the use of the Max Metric/ zero bw. We
will be posting an updated version later tonight. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: Dimitri.Papadimitriou <at> alcatel.be 
> [mailto:Dimitri.Papadimitriou <at> alcatel.be] 
> Sent: Friday, March 03, 2006 6:46 PM
> To: Zafar Ali (zali)
> Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp <at> ops.ietf.org; 
> dpapadimitriou <at> psg.com; Jean Philippe Vasseur (jvasseur); 
> Kireeti Kompella; owner-ccamp <at> ops.ietf.org
> Subject: RE: Need to close on signaling solution for graceful 
> shutdown (Follow-up on our Action Item)
> 
> hi zafar
> 
> then i will express my concern in the other way around 
> concerning the "routing" part of this document: we have clean 
> procedures for planned node restart in RFC4203; hence, the 
> reason for having a "cleaner" procedure is totally unclear to 
(Continue reading)


Gmane