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

[John Drake <[e-mail]>]

Francois,

You're very welcome.

John

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[e-mail]]
> Sent: Tuesday, November 09, 2004 1:43 PM
> To: John Drake
> Cc: FLF; [e-mail]
> Subject: FW: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt
> 
> 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