[Tsvwg] FW: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt

["Francois Le Faucheur \(flefauch\)" <[e-mail]>]

Hi John,

As discussed today, we will bring the next revision of
draft-lefaucheur-rsvp-dste in closer alignment with "LSP Hierarchy"
draft. In particular, the IF_ID RSVP_HOP object will be used as per "LSP
Hierarchy". I think we could also even go for out of band signaling
(also as per "LSP Hierarchy"), then we would probably want to do the
"checks" to confirm proper out-of-band signaling.

Thanks again for your comments.

Francois

>> -----Original Message-----
>> From: John Drake [mailto:[e-mail]] 
>> Sent: mardi 9 novembre 2004 17:59
>> To: John Drake; Francois Le Faucheur (flefauch)
>> Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch)
>> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt
>> 
>> Francois,
>> 
>> I just checked the hierarchy I-D and the two checks you 
>> mentioned are for
>> the out-of-band case.  I.e., you want to check that the far 
>> end of the FA
>> LSP is associated with the node that sent you the Path message.
>> 
>> You could probably state in your I-D that for this check 
>> isn't necessary for
>> the in-band case.  I don't know if you should mention that a 
>> node should
>> check the FA LSP specified in the IF_ID is the same as the 
>> LSP in which the
>> Path message was received.
>> 
>> Thanks,
>> 
>> John 
>> 

>> > > >> -----Original Message-----
>> > > >> From: John Drake [mailto:[e-mail]]
>> > > >> Sent: lundi 18 octobre 2004 18:20
>> > > >> To: Francois Le Faucheur (flefauch)
>> > > >> Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch);
>> > > >> Carol Iturralde (cei)
>> > > >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt
>> > > >>
>> > > >> Francois,
>> > > >>
>> > > >> The issue may be a simple as the fact that you don't make it
>> > > >> clear that you
>> > > >> are using LSP hierarchy as a base and that you don't
>> > > >> explicitly detail what
>> > > >> the differences are.  This makes your I-D read as though it
>> > > >> is proposing
>> > > >> something different.
>> > > >>
>> > > >> I would suggest that you include a normative reference to
>> > > >> the LSP hierarchy
>> > > >> I-D and indicate that its signaling procedures are to be
>> > > >> used; in particular
>> > > >> that the FA LSP is identified using the IF_ID RSVP_HOP.  (I
>> > > >> think it would
>> > > >> also help if you used its terminology.)
>> > > >>
>> > > >> Comments inline.
>> > > >>
>> > > >> Thanks,
>> > > >>
>> > > >> John
>> > > >>
>> > > >> > -----Original Message-----
>> > > >> > From: Francois Le Faucheur (flefauch) 
>> [mailto:[e-mail]]
>> > > >> > Sent: Monday, October 18, 2004 8:27 AM
>> > > >> > To: John Drake
>> > > >> > Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch);
>> > > >> Carol Iturralde
>> > > >> > (cei)
>> > > >> > Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt
>> > > >> >
>> > > >> > Hi John,
>> > > >> >
>> > > >> > Thanks for checking the document.
>> > > >> [John Drake]
>> > > >>
>> > > >> You're welcome.
>> > > >>
>> > > >> >
>> > > >> > >> -----Original Message-----
>> > > >> > >> From: John Drake [mailto:[e-mail]]
>> > > >> > >> Sent: vendredi 15 octobre 2004 18:02
>> > > >> > >> To: Francois Le Faucheur (flefauch)
>> > > >> > >> Cc: Francois Le Faucheur (flefauch); Bruce Davie (bdavie)
>> > > >> > >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt
>> > > >> > >>
>> > > >> > >> Francois,
>> > > >> > >>
>> > > >> > >> Is there a reason why you couldn't re-use the signaling
>> > > >> > >> procedures of the
>> > > >> > >> LSP hierarchy I-D?
>> > > >> >
>> > > >> > This is what we have tried to do.
>> > > >> > The LSP hierarchy draft does specify a number of ways to
>> > > >> signal from
>> > > >> > Aggregate Head to Aggregate Tail. In particular, it
>> > > >> discusses one option
>> > > >> > that is required for non-packet-capable optical boxes
>> > > >> (RSVP out of band)
>> > > >> > and one option which can be used for packet-capable boxes
>> > > >> (encpasulate
>> > > >> > inside tunnel). We use the latter option.
>> > > >> [John Drake]
>> > > >>
>> > > >> That's fine, but it does stipulate that in all cases 
>> the FA LSP is
>> > > >> identified with the IF_ID RSVP_HOP.
>> > > >>
>> > > >> >
>> > > >> > As I said, one necessary difference comes from the fact
>> > > >> that RSVP uses
>> > > >> > final destination while RSVP-TE uses ERO. But as you say
>> > > >> below, that
>> > > >> > doesn't affect things once it is encapsulated.
>> > > >> >
>> > > >> > >>If the Path message is tunneled from head-end to
>> > > >> > >> tail-end, as described in LSP hierarchy I-D, it doesn't
>> > > >> > >> matter what is in
>> > > >> > >> the destination address field of tunneled IP packet.
>> > > >> > >>  Also,
>> > > >> > >> in checking with
>> > > >> > >> Lou Berger, it seems that all RSVP-TE 
>> implementations place
>> > > >> > >> the next hop
>> > > >> > >> address in the destination address field.
>> > > >> >
>> > > >> > Agreed.
>> > > >> > Which is why we see a small difference in how to handle
>> > > >> aggregation of
>> > > >> > end-to-end RSVP from that viewpoint.
>> > > >> >
>> > > >> > >>
>> > > >> > >> It seems to me that having multiple ways of doing the
>> > > >> same thing is
>> > > >> > >> counter-productive.
>> > > >> > >> Also, in section 5, you seem to be recommending that your
>> > > >> > >> procedures, rather
>> > > >> > >> than the procedures of the LSP hierarchy I-D, be used for
>> > > >> > >> LSP hierarchy.
>> > > >> >
>> > > >> > We are not trying to introduce any change over LSP
>> > > >> hierarchy. Again, we
>> > > >> > think the behavior is in line with LSP hiererachy 
>> draft wherever
>> > > >> > possible and only differs for what is specific to RSVP
>> > > >> end-to-end flows.
>> > > >> > Please let us know if you see specific aspects which would
>> > > >> be departing
>> > > >> > from LSP hierarchy and which could be brought back in line.
>> > > >> >
>> > > >> > Thanks
>> > > >> >
>> > > >> > Francois
>> > > >> >
>> > > >> >
>> > > >> > >>
>> > > >> > >> Thanks,
>> > > >> > >>
>> > > >> > >> John
>> > > >> > >>
>> > > >> > >> > -----Original Message-----
>> > > >> > >> > From: Francois Le Faucheur (flefauch)
>> > > >> [mailto:[e-mail]]
>> > > >> > >> > Sent: Friday, October 15, 2004 3:31 AM
>> > > >> > >> > To: John Drake
>> > > >> > >> > Cc: Francois Le Faucheur (flefauch); Bruce 
>> Davie (bdavie)
>> > > >> > >> > Subject: RE: I-D 
>> ACTION:draft-lefaucheur-rsvp-dste-01.txt
>> > > >> > >> >
>> > > >> > >> > Hi John,
>> > > >> > >> >
>> > > >> > >> > Thanks for the note. Yes, we are aware of that draft
>> > > >> and also see a
>> > > >> > >> > number of commonalities. In fact, in section 
>> 5, we point
>> > > >> > >> out that one of
>> > > >> > >> > the applicable scenario is the one where the end-to-end
>> > > >> > >> reservations are
>> > > >> > >> > RSVP-TE tunnel reservations as per lsp-hiererachy.
>> > > >> > >> > However, the prime focus of the rsvp-dste draft is,
>> > > >> of course, the
>> > > >> > >> > aggregation of regular RSVP reservations and its
>> > > >> > >> applicablity to CAC for
>> > > >> > >> > voice. One of the related aspect is that RSVP-TE
>> > > >> > >> reservations use ERO
>> > > >> > >> > while regular RSVP Path uses final destination 
>> addresses.
>> > > >> > >> This makes it
>> > > >> > >> > much more natural with regular RSVP to encapuslate the
>> > > >> > >> Path inside the
>> > > >> > >> > tunnel, than with lsp-hiererachy where Path message
>> > > >> can be forwrded
>> > > >> > >> > out-of-band to the Tunnel tail.
>> > > >> > >> >
>> > > >> > >> > Looking forward to hearing more comments
>> > > >> > >> >
>> > > >> > >> > Francois
>> > > >> > >> >
>> > > >> > >> > >> -----Original Message-----
>> > > >> > >> > >> From: John Drake [mailto:[e-mail]]
>> > > >> > >> > >> Sent: jeudi 14 octobre 2004 23:05
>> > > >> > >> > >> To: Francois Le Faucheur (flefauch)
>> > > >> > >> > >> Subject: FW: I-D 
>> ACTION:draft-lefaucheur-rsvp-dste-01.txt
>> > > >> > >> > >>
>> > > >> > >> > >> Francois,
>> > > >> > >> > >>
>> > > >> > >> > >> Are you aware of the following I-D:
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hiera
>> > > >> > >> > >> rchy-08.txt
>> > > >> > >> > >>
>> > > >> > >> > >> I think there's a fair amount of overlap between
>> > > >> it and your
>> > > >> > >> > >> draft, below,
>> > > >> > >> > >> which I just skimmed.  (And which I'll read 
>> more thoroughly
>> > > >> > >> > >> later this
>> > > >> > >> > >> week.)
>> > > >> > >> > >>
>> > > >> > >> > >> Thanks,
>> > > >> > >> > >>
>> > > >> > >> > >> John
>> > > >> > >> > >>
>> > > >> > >> > >> -----Original Message-----
>> > > >> > >> > >> From: [e-mail]
>> > > >> [mailto:[e-mail]]
>> > > >> > >> > >> Sent: Thursday, October 14, 2004 1:18 PM
>> > > >> > >> > >> To: [e-mail]
>> > > >> > >> > >> Subject: I-D 
>> ACTION:draft-lefaucheur-rsvp-dste-01.txt
>> > > >> > >> > >>
>> > > >> > >> > >> A New Internet-Draft is available from the on-line
>> > > >> > >> Internet-Drafts
>> > > >> > >> > >> directories.
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> > >> > >> 	Title		: Aggregation of RSVP
>> > > >> > >> Reservations over MPLS
>> > > >> > >> > >> TE/DS-TE
>> > > >> > >> > >> 			  Tunnels
>> > > >> > >> > >> 	Author(s)	: F. Le Faucheur, et al.
>> > > >> > >> > >> 	Filename	: 
>> draft-lefaucheur-rsvp-dste-01.txt
>> > > >> > >> > >> 	Pages		: 18
>> > > >> > >> > >> 	Date		: 2004-10-14
>> > > >> > >> > >>
>> > > >> > >> > >> This document provides specification for 
>> aggregation of
>> > > >> > >> RSVP end-to-
>> > > >> > >> > >>    end reservations over MPLS Traffic 
>> Engineering (TE)
>> > > >> > >> > >> tunnels or MPLS
>> > > >> > >> > >>    Diffserv-aware MPLS Traffic Engineering (DS-TE)
>> > > >> Tunnels. This
>> > > >> > >> > >>    approach is based on RFC 3175 and simply 
>> modifies the
>> > > >> > >> > >> corresponding
>> > > >> > >> > >>    procedures for operations over MPLS TE tunnels
>> > > >> instead of
>> > > >> > >> > >> aggregated
>> > > >> > >> > >>    RSVP reservations. This approach can be used to
>> > > >> > >> achieve admission
>> > > >> > >> > >>    control of a very large number of flows 
>> in a scalable
>> > > >> > >> > >> manner since
>> > > >> > >> > >>    the devices in the core of the network are
>> > > >> unaware of the
>> > > >> > >> > >> end-to-end
>> > > >> > >> > >>    RSVP reservations and are only aware of the
>> > > >> MPLS TE tunnels.
>> > > >> > >> > >>
>> > > >> > >> > >> A URL for this Internet-Draft is:
>> > > >> > >> > >>
>> > > >> > >>
>> > > >> 
>> http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt
>> > > >> > >> > >>
>> > > >> > >> > >> To remove yourself from the I-D 
>> Announcement list, send
>> > > >> > >> a message to
>> > > >> > >> > >> [e-mail] 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-lefaucheur-rsvp-dste-01.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:
>> > > >> > >> > >> 	[e-mail].
>> > > >> > >> > >> In the body type:
>> > > >> > >> > >> 	"FILE
>> > > >> > >> /internet-drafts/draft-lefaucheur-rsvp-dste-01.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.
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> -------------------------------------------------------------
>> > > >> > >> > >> ------------
>> > > >> > >> > >> In order to maintain computing 
>> infrastructure integrity,
>> > > >> > >> > >> Cisco Systems
>> > > >> > >> > >> Enterprise Messaging Services and InfoSec 
>> teams have set a
>> > > >> > >> > >> mail policy
>> > > >> > >> > >> disallowing executable attachments in email.
>> > > >> > >> > >>
>> > > >> > >> > >> This message contained an executable attachment
>> > > >> type that is
>> > > >> > >> > >> prohibited
>> > > >> > >> > >> by this policy. The attachment has been 
>> removed from this
>> > > >> > >> > >> message and
>> > > >> > >> > >> copied to quarantine by our systems. It 
>> will be held in
>> > > >> > >> > >> quarantine for
>> > > >> > >> > >> seven days in the event that the content needs to
>> > > >> be retrieved.
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> -------------------------------------------------------------
>> > > >> > >> > >> ------------
>> > > >> > >> > >> For further reference information about viruses and
>> > > >> > >> email antivirus
>> > > >> > >> > >> efforts within Cisco, please visit:
>> > > >> > >> > >>
>> > > >> > >> > >> http://wwwin.cisco.com/it/ems/services/antiviral
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> > >> > >> If your concern isn't addressed by the 
>> information in this
>> > > >> > >> > >> notification
>> > > >> > >> > >> or the above web page, you may open a 
>> support request:
>> > > >> > >> > >>
>> > > >> > >> > >> http://wwwin.cisco.com/support/
>> > > >> > >> > >>
>> > > >> > >> > >> Select "Messaging", "Email-Related", "Mail Routing"
>> > > >> > >> > >>
>> > > >> > >> > >> Please include in the text of your case the 
>> following
>> > > >> > >> information:
>> > > >> > >> > >>
>> > > >> > >> > >> * Full headers of the message. Documentation on
>> > > >> > >> displaying the full
>> > > >> > >> > >> headers is available at this URL:
>> > > >> > >> > >>
>> > > >> > >> > >>
>> > > >> 
>> http://wwwin.cisco.com/support/library/faqs/solution002471.html
>> > > >> > >> > >>
>> > > >> > >> > >> * This unique quarantine identifier: i9EL4Ew8014772
>> > > >> > >> > >>
>> > > >> > >> > >> If the matter is urgent, you may follow up by
>> > > >> calling one of
>> > > >> > >> > >> the below
>> > > >> > >> > >> referenced numbers. Please make every 
>> effort to provide
>> > > >> > >> the above
>> > > >> > >> > >> requested information via the support web 
>> tool prior to
>> > > >> > >> > >> calling as it
>> > > >> > >> > >> will greatly aid the resolution of your issue.
>> > > >> > >> > >>
>> > > >> > >> > >> Americas:
>> > > >> > >> > >> 1 408 526 8888
>> > > >> > >> > >>
>> > > >> > >> > >> Asiapac
>> > > >> > >> > >> [phone]
>> > > >> > >> > >>
>> > > >> > >> > >> EMEA
>> > > >> > >> > >> [phone]
>> > > >> > >> > >>
>> > > >> > >> > >> Japan
>> > > >> > >> > >> [phone]
>> > > >> > >> > >>
>> > > >> > >> > >> US (Toll Free)
>> > > >> > >> > >> 1| 800| 888| 8187| (ext.68888)
>> > > >> > >> > >>
>> > > >> > >> > >> Thank you for your cooperation,
>> > > >> > >> > >>
>> > > >> > >> > >> Enterprise Messaging Services
>> > > >> > >> > >> Cisco Systems, Inc
>> > > >> > >> > >>
>> > > >> > >>
>> > > >>
>> 

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg