Subject: Fw: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 May 2006 00:20:29 +0100

Hi,

Here are the results of the anonymous survey of ERO usage that was triggered 
by the Dallas discussion of the GMPLS Addressing I-D.

I have drawn some preliminary conclusions and included my advice in section 
5.

Please have a look at the whole and make your comments to the list.

Thanks,
Adrian

PS If there is a bunch of other folk who suddenly feel the need to respond, 
I can always produce a revised I-D.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 11, 2006 8:50 PM
Subject: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
> Title : Informal Survey into Explicit Route Object Implementations in 
> Generalized Multiprotocol Labels Switching Signaling Implementations
> Author(s) : A. Farrel
> Filename : draft-farrel-ccamp-ero-survey-00.txt
> Pages : 12
> Date : 2006-5-11
>
>   During discussions of a document to provide guidance on the use of
>   addressing fields within the Resource Reservation Protocol Traffic
>   Engineering (RSVP-TE) signaling protocol used in Generalized
>   Multiprotocol Label Switching (GMPLS), it was determined that there
>   was considerable variation in the implementation of options for the
>   Explicit Route Object (ERO).
>
>   Since there was a proposal to deprecate some of the options, it was
>   felt necessary to conduct a survey of the existing and planned
>   implementations.
>
>   This document summarizes the survey questions and captures the
>   results. Some conclusions are also presented.
>
>   This survey was informal and conducted via email. Responses were
>   collected and anonymized by the CCAMP working group chair.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ero-survey-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-farrel-ccamp-ero-survey-00.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:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-farrel-ccamp-ero-survey-00.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.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Fri, 12 May 2006 10:49:21 +0200

Hi Adrian.

Let me quote:

"  individual who, although (or perhaps because) he is a working group
   chair, cannot necessarily be trusted. Thus, the IETF process is
   open to an attack by this individual."

I'm inclined to ask the following question: should the IETF stop allowing such attack, or should we modify the chair implementation so as to inhibit such behaviour? ;-)

For the chair's sake, I'd rather change the receiving side to handle as many behaviours as possible, but I feel reducing sender's options will ease interoperability. As a result, I agree with your proposed actions, especially about making implementations converge on really required options.

Cheers,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel

Hi,

Thanks,
Adrian

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 12 May 2006 11:10:06 +0200

Hi Julien,
           as a Carrier representative do you think that from your
prespective some ERO implementations are better than other?

E.g. from a carrier prespective having the possibility to use explicit ERO
with component link and label specification is nice_to_have, mandatory or
useless?

The above is just an example I'm not pushing a solution that include
component link and label.

Regards

Diego

"MEURIC Julien RD-CORE-LAN" <[email-masked]>@ops.ietf.org
on 12/05/2006 10.49.21

Sent by:    [email-masked]

To:    <[email-masked]>
cc:    <[email-masked]>

Subject:    RE: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt

Hi Adrian.

Let me quote:

I'm inclined to ask the following question: should the IETF stop allowing
such attack, or should we modify the chair implementation so as to inhibit
such behaviour? ;-)

For the chair's sake, I'd rather change the receiving side to handle as
many behaviours as possible, but I feel reducing sender's options will ease
interoperability. As a result, I agree with your proposed actions,
especially about making implementations converge on really required
options.

Cheers,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel

Hi,

Here are the results of the anonymous survey of ERO usage that was
triggered
by the Dallas discussion of the GMPLS Addressing I-D.

5.

Thanks,
Adrian

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Fri, 12 May 2006 16:14:17 +0200

Hi Diego.

It looks like you're requiring some requirements! As a matter of fact,
I'm thinking about it, but it should not overlap with what's addressed
in the addressing draft...

Regards,

Julien

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]] 

Hi Julien,

E.g. from a carrier prespective having the possibility to use explicit
ERO
with component link and label specification is nice_to_have, mandatory
or
useless?

Regards

Diego

"MEURIC Julien RD-CORE-LAN"
<[email-masked]>@ops.ietf.org
on 12/05/2006 10.49.21

Hi Adrian.

Let me quote:

I'm inclined to ask the following question: should the IETF stop
allowing
such attack, or should we modify the chair implementation so as to
inhibit
such behaviour? ;-)

For the chair's sake, I'd rather change the receiving side to handle as
many behaviours as possible, but I feel reducing sender's options will
ease
interoperability. As a result, I agree with your proposed actions,
especially about making implementations converge on really required
options.

Cheers,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf
Of Adrian Farrel

Hi,

I have drawn some preliminary conclusions and included my advice in
section

5.

Thanks,
Adrian

PS If there is a bunch of other folk who suddenly feel the need to
respond,

----- Original Message -----

> implementation to automatically retrieve the ASCII version of the

------------------------------------------------------------------------
--------