- NANOG - lists.nanog.org

MPLS/TE in today's networks
by Shawn H 26 May '01

26 May '01

Hi, I'm a student currently researching MPLS/TE technologies. With all the proposed methods and functionalities, I was wondering if anyone has some useful information/pointers to answers to the following questions: * How widely is traffic engineering over MPLS deployed in today's networks? * What applications of MPLS are in use today (TE, protection, BGP nexthop resolution, VPNs, etc)? * How widely used are TE offline planning tools? * How do different vendors affect different deployments? That is, are the common functionalities mostly in use, or are there different proprietary methods used in different networks/SPs? Thanks a lot for any useful information, Shawn. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0

RE: E-mail vs. FTP -- ***RTF RFC***
by Roeland Meyer 26 May '01

26 May '01

One of my clients, a largish dot-com, tried this ... resounding lack of success. The end-user community did NOT like it when an email arrived with links. They were too afraid that the link might point to a virus, among other things (yeah, I know, but YOU try fighting FUD for a while). > -----Original Message----- > From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > Sent: Saturday, May 26, 2001 7:57 AM > To: nanog(a)nanog.org > Subject: E-mail vs. FTP -- ***RTF RFC*** > > > > Greetings all, > > Section 7.3.3 of RFC1341 addresses the external storage, > expiry, et cetera > issues. Not perfect, but a good first pass... and almost ten > years old, > too. > > ((( Thanks to Valdis for pointing this out! ))) > > We could probably kludge FTP as an interim measure: > > * MTA intercepts attachments, and spools them separately. > > * "access-type: ftp" with, e.g., username "msg12345recipient67890" and > password "mi93et490" and "expiration: Mon, 28 May 2001 > 00:00:00 +0000". > The specific parameters would be generated on a per-message basis. > > * Mail admins can enforce quotas. Nothing new. The > arguments in favor of > electronic transfer are on the grounds of timely communication. One > could argue that somebody not checking mail for a week > doesn't deserve > to receive their attachment without a second > "transmission". The proxy > MTA could insert a human-readable expiration notice or > whatever other > user-friendly prompting is deemed to be a good idea. > > * We could also forget the MIME method, and put in a > human-readable link > to get the attachment, a la electronic greeting cards. > This would allow > immediate use of non-registered access-type methods. > > Eventually, I'd like to see this done via HTTP/1.1 using chunked > transfers. However, no current MUAs will support a non-existant HTTP > method or any X-Experimental methods. For something that would work > *right now*, I think that RTF RFC and going from there is the > right way... > > Does anybody know what MUAs follow the RFC for external > message content? > A little smtpd and ftpd hacking could yield something workable PDQ. > > > Eddy > > -------------------------------------------------------------- > ------------- > > Brotsman & Dreger, Inc. > EverQuick Internet Division > > Phone: (316) 794-8922 > > -------------------------------------------------------------- > ------------- > > Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) > From: A Trap <blacklist(a)brics.com> > To: blacklist(a)brics.com > Subject: Please ignore this portion of my mail signature. > > These last few lines are a trap for address-harvesting > spambots. Do NOT > send mail to <blacklist(a)brics.com>, or you are likely to be blocked. > >

1 0

RE: Email Parcel Post is Good!
by Roeland Meyer 26 May '01

26 May '01

> that and a small perl script are how i get all the internet drafts and > rfcs as they are published. Do you seriously expect a marketing VP to write perl?

6 6

Re: PacBell Frame Relay Outage?
by Sean Donelan 26 May '01

26 May '01

On Fri, 25 May 2001, Roy wrote: > Is anyone else experiencing an outage in the PacBell Frame Relay cloud in > the SF Bay area.? 75% of my PVCs are down and the trouble number is busy or > you go into "hold" forever. Pacbell statement at 11:04am PDT: Some customers in California and Reno may be unable to access the Internet at this time do to an equipment problem. Our Engineering Team is working to resolve this issue. We apologize for any inconvenience this may cause and thank you for your patience.

3 2

RE: EMAIL != FTP
by Roeland Meyer 26 May '01

26 May '01

> From: Mitch Halmu [mailto:mitch@netside.net] > Sent: Saturday, May 26, 2001 7:49 AM > Scary stuff that you > haven't even thought of could happen with 8 bit message bodies... Like voice-grade email ...

1 0

RE: Stealth Blocking
by Roeland Meyer 26 May '01

26 May '01

> From: Mitch Halmu [mailto:mitch@netside.net] > Sent: Thursday, May 24, 2001 2:48 PM > > On Thu, 24 May 2001, Matt Cramer wrote: > I will give you a solid reason why we won't try this, quoting > research > with POP-before-SMTP conducted by the founder of MAPS TSI, > Chip Rosenthal > http://users.laserlink.net/~chip/relay-pres-9910/ > > You don't have to believe me that our clients will not accept > that, take > his words instead: > > "Our users hated it - particularly those using MS Outlook" > > No need to describe what happens when your clients hate your > service... On that same page, I found this very interesting. The part about false positive, to normal relay testing, got my attention. Guys, there are more cases that may look like an open relay, but really aren't. <quote> Escalating Credentials Curently deployed in Laser Link network Amalgamation of two mechanisms: POP-before-SMTP Rate limiting Count mail from originating IP address ... Disadvantages: Complex implementation Will users accept upper limit? False positive to conventional relay testing </quote>

4 3

E-mail vs. FTP -- ***RTF RFC***
by E.B. Dreger 26 May '01

26 May '01

Greetings all, Section 7.3.3 of RFC1341 addresses the external storage, expiry, et cetera issues. Not perfect, but a good first pass... and almost ten years old, too. ((( Thanks to Valdis for pointing this out! ))) We could probably kludge FTP as an interim measure: * MTA intercepts attachments, and spools them separately. * "access-type: ftp" with, e.g., username "msg12345recipient67890" and password "mi93et490" and "expiration: Mon, 28 May 2001 00:00:00 +0000". The specific parameters would be generated on a per-message basis. * Mail admins can enforce quotas. Nothing new. The arguments in favor of electronic transfer are on the grounds of timely communication. One could argue that somebody not checking mail for a week doesn't deserve to receive their attachment without a second "transmission". The proxy MTA could insert a human-readable expiration notice or whatever other user-friendly prompting is deemed to be a good idea. * We could also forget the MIME method, and put in a human-readable link to get the attachment, a la electronic greeting cards. This would allow immediate use of non-registered access-type methods. Eventually, I'd like to see this done via HTTP/1.1 using chunked transfers. However, no current MUAs will support a non-existant HTTP method or any X-Experimental methods. For something that would work *right now*, I think that RTF RFC and going from there is the right way... Does anybody know what MUAs follow the RFC for external message content? A little smtpd and ftpd hacking could yield something workable PDQ. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

1 0

RE: EMAIL != FTP
by Roeland Meyer 26 May '01

26 May '01

> From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] > Sent: Saturday, May 26, 2001 5:05 AM > > Incorrect, IE: > > Right click over the link, "Save Target as" > > sure the browser wont display it correct but you can save it fine. Our Secretary/Treasurer has been using Windows for over 10 years. She's just now discovering the joys of "Right click".

1 0

Re: PacBell Frame Relay Outage?
by owen＠dixon.delong.sj.ca.us 26 May '01

26 May '01

The only balls I've seen from SBC lately are the ones they use when they go in front of the PUC (takes balls to ask for some of what they do), and the ball of water in their commercials for their super reliable data services. I noticed their commercials appeared to be MIA most of yesterday. :-) Owen > On Fri, May 25, 2001 at 12:48:40PM -0700, Sean Donelan wrote: > > > > Pacbell statement at 11:04am PDT: > > > > Some customers in California and Reno may be unable to access the > > Internet at this time do to an equipment problem. Our Engineering > > Team is working to resolve this issue. We apologize for any > > inconvenience this may cause and thank you for your patience. > > How delightfully non-descriptive. I hope it was at least "due" to an > equipment problem. > > Wouldn't it be easier if they just issued a magic 8ball instead of a > statement? > > "When will my internet be up?" > "Reply hazy, try again" > > -- > Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras > PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) > > >

1 0

Re: EMAIL != FTP
by David Lesher 26 May '01

26 May '01

A) A friend got bit badly by the "anything I can attach I will" syndrome. He was in the UK, and the usual USG local POP (from PSI) was FUBAR. So he called back to DC to get urgent mail. Some MITRE genius had attacked a 10+meg PowerPointless file to his message to 100+ folks, including Friend. Friend err (rather you & I) paid a VERY large phone bill for that braindeadness. B) I'm intrigued by the proposal for pseudo attachments. Hmm, what's really needed? 1) User still points & clicks. 2) MUA uploads attachment to its designated server. 3) MUA attaches URL & password to message. 4) Recipient gets mail and grabs attachment. 5) Server knows who has gotten file, keeps track. 6) 24 hours after last recipient has claimed it, or {say} 1 week later, it deletes it. Replaces with "it's expired, have it resent" for whenever. (Gee, this sounds like news and history files...) All this needs to work is for say Eudora and Mutt to both offer it. Once a critical mass of sysadms deploy same, and crank down the limit to 100K, more will. (I say Eudora because M$ will resist anything that interoperates....) -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0