headers
BRUNGARD, DEBORAH A (ATTLABS | 1 Apr 2010 05:17
Picon
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

It depends if you are specifying the data plane or mibs. Always, if selecting one sentence out of many, it is
not complete (as Eric says). This sentence from RFC5654 was more from the data plane view using the
familiar packet term "dropped" vs. transport's G.808.1 "discarded".

I also agree we don't want to load this too much. "Reject" is not familiar wording. Suggest using then
wording from G808.1:
"External commands which are preempted or denied by other higher priority conditions, states or
requests, are discarded."

I think the choices are: "denied" or "discarded".

-----Original Message-----
From: Manuel.Paul <at> telekom.de [mailto:Manuel.Paul <at> telekom.de] 
Sent: Wednesday, March 31, 2010 9:42 AM
To: eric.gray <at> ericsson.com; lieven.levrau <at> alcatel-lucent.com; benjamin.niven-jenkins <at> bt.com;
italo.busi <at> alcatel-lucent.com; rfc-editor <at> rfc-editor.org; BRUNGARD, DEBORAH A (ATTLABS);
malcolm.betts <at> huawei.com; nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com; rcallon <at> juniper.net;
adrian.farrel <at> huawei.com; swallow <at> cisco.com; loa <at> pi.nu
Cc: mpls <at> ietf.org
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)

I also believe that we need to phrase it stronger than just saying "drop" or "ignore" - to imply that some
(whatever) kind of feedback to the "requester" needs to be considered as well.
Using "reject" makes sense for me.

Regards,
Manuel

> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On
(Continue reading)

Permalink | Reply | 7 comments |
headers
D'Alessandro Alessandro Gerardo | 1 Apr 2010 13:02
Picon
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

I agree with Manuel's comment (some feedback to the operator shall be considered).
About the correct word to be used, I'm fine with either "reject" or "discard" clarifying the previous point.

Regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Original Message-----
From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS)
Sent: giovedì 1 aprile 2010 5.18
To: Manuel.Paul <at> telekom.de; eric.gray <at> ericsson.com; lieven.levrau <at> alcatel-lucent.com;
benjamin.niven-jenkins <at> bt.com; italo.busi <at> alcatel-lucent.com; rfc-editor <at> rfc-editor.org;
malcolm.betts <at> huawei.com; nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com; rcallon <at> juniper.net;
adrian.farrel <at> huawei.com; swallow <at> cisco.com; loa <at> pi.nu
Cc: mpls <at> ietf.org
Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073)

It depends if you are specifying the data plane or mibs. Always, if selecting one sentence out of many, it is
not complete (as Eric says). This sentence from RFC5654 was more from the data plane view using the
familiar packet term "dropped" vs. transport's G.808.1 "discarded".

I also agree we don't want to load this too much. "Reject" is not familiar wording. Suggest using then
wording from G808.1:
(Continue reading)

Permalink | Reply | 6 comments |
headers
BUSI ITALO | 1 Apr 2010 17:29
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

I understand that Deborah has some issues with "reject".

Therefore it looks like that we can converge on "discard".

Is "discard" acceptable?

For me it is fine.

Thanks, Italo

P.S. Please note my new email address, Italo.Busi <at> alcatel-lucent.com, effective since 1 November 2009.

> -----Original Message-----
> From: D'Alessandro Alessandro Gerardo 
> [mailto:alessandro.dalessandro <at> telecomitalia.it] 
> Sent: giovedì 1 aprile 2010 13.03
> To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul <at> telekom.de; 
> eric.gray <at> ericsson.com; LEVRAU LIEVEN; 
> benjamin.niven-jenkins <at> bt.com; BUSI ITALO; 
> rfc-editor <at> rfc-editor.org; malcolm.betts <at> huawei.com; 
> nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com; 
> rcallon <at> juniper.net; adrian.farrel <at> huawei.com; 
> swallow <at> cisco.com; loa <at> pi.nu
> Cc: mpls <at> ietf.org
> Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)
> 
> I agree with Manuel's comment (some feedback to the operator 
> shall be considered).
> About the correct word to be used, I'm fine with either 
> "reject" or "discard" clarifying the previous point.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric Gray | 1 Apr 2010 17:46
Picon
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

Discard is fine with me.

-----Original Message-----
From: BUSI ITALO [mailto:Italo.Busi <at> alcatel-lucent.com]
Sent: Thursday, April 01, 2010 11:29 AM
To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul <at> telekom.de; Eric
Gray; LEVRAU LIEVEN; benjamin.niven-jenkins <at> bt.com; rfc-editor <at> rfc-editor.org;
malcolm.betts <at> huawei.com; nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com; rcallon <at> juniper.net;
adrian.farrel <at> huawei.com; swallow <at> cisco.com; loa <at> pi.nu
Cc: mpls <at> ietf.org
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)
Importance: High

I understand that Deborah has some issues with "reject".

Therefore it looks like that we can converge on "discard".

Is "discard" acceptable?

For me it is fine.

Thanks, Italo

P.S. Please note my new email address, Italo.Busi <at> alcatel-lucent.com, effective since 1 November 2009.

> -----Original Message-----
> From: D'Alessandro Alessandro Gerardo
> [mailto:alessandro.dalessandro <at> telecomitalia.it]
> Sent: giovedì 1 aprile 2010 13.03
> To: BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul <at> telekom.de;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lam, Hing-Kam (Kam | 1 Apr 2010 17:48
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

If there is a choice, I prefer "reject" over "discard".

Reason: to me "discard", "drop", and "ignore" are semantically equivalent. They all imply "silently"
drop/ignore/discard and therefore the requestor has no idea what is going on. "Reject" or "Denied" imply
there is an (negative) acknowledgement.

But since "discard" is quoted from G.808.1, I can live with it. :-(

Regards,
Kam
P.S. I have replaced Malcolm's former email address with the latest one.

> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> BUSI ITALO
> Sent: Thursday, April 01, 2010 11:29 AM
> To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS);
> Manuel.Paul <at> telekom.de; eric.gray <at> ericsson.com; LEVRAU, LIEVEN (LIEVEN);
> benjamin.niven-jenkins <at> bt.com; rfc-editor <at> rfc-editor.org;
> malcolm.betts <at> huawei.com; nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com;
> rcallon <at> juniper.net; adrian.farrel <at> huawei.com; swallow <at> cisco.com;
> loa <at> pi.nu
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073)
>
> I understand that Deborah has some issues with "reject".
>
> Therefore it looks like that we can converge on "discard".
>
> Is "discard" acceptable?
(Continue reading)

Permalink | Reply | 1 comment |
headers
D'Alessandro Alessandro Gerardo | 1 Apr 2010 17:49
Picon
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

For me too.

------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Original Message-----
From: Eric Gray [mailto:eric.gray <at> ericsson.com]
Sent: giovedì 1 aprile 2010 17.47
To: BUSI ITALO; D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS);
Manuel.Paul <at> telekom.de; LEVRAU LIEVEN; benjamin.niven-jenkins <at> bt.com;
rfc-editor <at> rfc-editor.org; malcolm.betts <at> huawei.com; nurit.sprecher <at> nsn.com;
satoshi.ueno <at> ntt.com; rcallon <at> juniper.net; adrian.farrel <at> huawei.com; swallow <at> cisco.com; loa <at> pi.nu
Cc: mpls <at> ietf.org
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)

Discard is fine with me.

-----Original Message-----
From: BUSI ITALO [mailto:Italo.Busi <at> alcatel-lucent.com]
Sent: Thursday, April 01, 2010 11:29 AM
To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS); Manuel.Paul <at> telekom.de; Eric
Gray; LEVRAU LIEVEN; benjamin.niven-jenkins <at> bt.com; rfc-editor <at> rfc-editor.org;
malcolm.betts <at> huawei.com; nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com; rcallon <at> juniper.net;
adrian.farrel <at> huawei.com; swallow <at> cisco.com; loa <at> pi.nu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Gray | 1 Apr 2010 18:00
Picon
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

Kam,

        See my reply to Alessandro on this subject.

--
Eric

-----Original Message-----
From: Lam, Hing-Kam (Kam) [mailto:kam.lam <at> alcatel-lucent.com]
Sent: Thursday, April 01, 2010 11:48 AM
To: BUSI, ITALO (ITALO); D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A (ATTLABS);
Manuel.Paul <at> telekom.de; Eric Gray; LEVRAU, LIEVEN (LIEVEN); benjamin.niven-jenkins <at> bt.com;
rfc-editor <at> rfc-editor.org; nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com;
rcallon <at> juniper.net; adrian.farrel <at> huawei.com; swallow <at> cisco.com; loa <at> pi.nu; Malcolm.BETTS <at> zte.com.cn
Cc: mpls <at> ietf.org
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)
Importance: High

If there is a choice, I prefer "reject" over "discard".

Reason: to me "discard", "drop", and "ignore" are semantically equivalent. They all imply "silently"
drop/ignore/discard and therefore the requestor has no idea what is going on. "Reject" or "Denied" imply
there is an (negative) acknowledgement.

But since "discard" is quoted from G.808.1, I can live with it. :-(

Regards,
Kam
P.S. I have replaced Malcolm's former email address with the latest one.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Gray | 1 Apr 2010 18:00
Picon
Favicon

Re: [Editorial Errata Reported] RFC5654 (2073)

Alessandro,

        I think most people agree with this point, yet the fact that an
implementer may need to implement certain "usability" features is not
the point in defining protocol standards.

        More and more in the IETF, we tend to do this anyway, because it
is important to the customers.  However, while this tendency exists,
the fact remains that this is a "motherhood and apple pie" factor with
not so much importance from the perspective of defining interoperable
standards.  From that perspective, what is important is that vendors
all agree in their implementations on the fact that only the highest
priority imperative present at any point in time is acted on.

        Put another way, if my implementation notifies the user that a
specific command was ignored because of an existing higher priority
imperative/condition - and vendor X's implementation does not - my
implementation is likely to make my customers happier than vendor X's
(at least in this one respect), but the ability of our implementations
to correctly interoperate is simply not affected by this distinction.

        Because ambiguity on this point has no impact on interoperability,
it is not as important to clarify this.

--
Eric

-----Original Message-----
From: D'Alessandro Alessandro Gerardo [mailto:alessandro.dalessandro <at> telecomitalia.it]
Sent: Thursday, April 01, 2010 7:03 AM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel.Paul | 1 Apr 2010 18:12
Picon

Re: [Editorial Errata Reported] RFC5654 (2073)

I also see Deborah's point if only the data plane is concerned. However, as the chapter adresses functions
for control by the operator and is headlined "Management-Plane Operation of Protection and
Restoration", I felt it is usefull to having this as a "traceable event" (like I think Eric called it earlier).

If the majority is fine with it, however, I could live with "discard".

(and I saw some mails coming in while I was typing this...)

But, in case of using "discard", wouldn't we need to add the word "requests" to the sentence as well?
I.E. making it:   
] A.  External control requests...  [  
instead of    
] A.  External controls ... [

Remember, up to now the RFC text says "control", not "control messages" or "control requests".
(and as I had understood, clarifying this was Eric's main motivation...)

Thanks,
Manuel

> -----Original Message-----
> From: BUSI ITALO [mailto:Italo.Busi <at> alcatel-lucent.com] 
> Sent: Thursday, April 01, 2010 5:29 PM
> To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A 
> (ATTLABS); Paul, Manuel; eric.gray <at> ericsson.com; LEVRAU 
> LIEVEN; benjamin.niven-jenkins <at> bt.com; 
> rfc-editor <at> rfc-editor.org; malcolm.betts <at> huawei.com; 
> nurit.sprecher <at> nsn.com; satoshi.ueno <at> ntt.com; 
> rcallon <at> juniper.net; adrian.farrel <at> huawei.com; 
> swallow <at> cisco.com; loa <at> pi.nu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Annamaria Fulignoli | 1 Apr 2010 20:59
Picon
Favicon

Re: Choice of BFD mechanism/mode for proactive CV/CC

Hi Greg,
sorry for the delay in answering.
You wrote: 
"what are reasons considered to select only unidirectional BFD (based on BFD for multipoint networks
work) for proactive CV/CC"

The unidirectional BFD allows to have one solution, one behavior, for all transport entities ( p2p
bidirectional, p2p unidirectional, p2mp ) and it satisfies all MPLS-TP transport requirement for the
proactive CV/CC, including also the unidirectional failure; it is very simple and fast tool as transport
operator require.

As it could be critical to support, the group is still working together to converge asap to a common agreed solution.

We'll be glad to receive your useful comments next draft update.
Thanks   
Best Regards
Annamaria 

________________________________

From: Greg Mirsky [mailto:gregimirsky <at> gmail.com] 
Sent: mercoledì 31 marzo 2010 18.16
To: Annamaria Fulignoli; sboutros <at> cisco.com; martin.vigoureux <at> alcatel-lucent.com;
swallow <at> cisco.com; David Ward; wardd <at> cisco.com; msiva <at> cisco.com; mpls <at> ietf.org; mpls-tp <at> ietf.org
Subject: Re: Choice of BFD mechanism/mode for proactive CV/CC

I haven't seen any response from authors thus assuming that it didn't make to the list the first time.

On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky <gregimirsky <at> gmail.com> wrote:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane