Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules

From: Christian Kaas-Petersen <[email-masked]>
Date: Wed, 15 Apr 2009 09:23:51 +0000 (GMT)

Actually, IETF 74th Thursday plenary on MPLS discussed the situation of
have alternative protocols (LDP vs RSVP was just one example) doing the
same thing.  The statements made by the speakers and from the floor
were: Yes it is a pain to implement two protocols, and yes it is a
pain to deploy two protocols.  However, most often it turns out, that
one of the protocols is left in oblivion when it has been seen running
in practice, and most often taking a second approach gives renewed input
or energy to the first approach, making it clear which of the two
approaches is the favoured one.  Thus I went away with the impression,
that staying with one approach is in fact not always the obvious thing
to do.

Christian 

--- Den ons 15/4/09 skrev marcelo bagnulo braun <[email-masked]>:

> Fra: marcelo bagnulo braun <[email-masked]>
> Emne: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules
> Til: "George Tsirtsis" <[email-masked]>
> Cc: "mext" <[email-masked]>, [email-masked]
> Dato: onsdag 15. april 2009 11.05
> George Tsirtsis escribió:
> > Hi Hesham,
> >
> > I think in fact the binary mechanism can easily be
> much more flexible
> > if we want to.
> >
> > All we have to do it to allow for matching to an
> "Offset" + "Number of
> > bytes". The Offset would be a pointer to X number of
> bytes from the
> > beginning of the IP header, and then the Number of
> Bytes, would be the
> > field that you are trying to match.
> > This has been used by classifiers for long time now
> (e.g., Linux, look
> > for U32 Selector).
> >
> > In that case, the fixed binary format can cover most
> of the cases and
> > also provide a mechanism for matching anything else in
> the packet,
> > which makes this really powerful.
> >
> > Having said that, while I agree with Marcelo that we
> should only
> > define what we need, there is little harm in defining
> additional
> > optional Flow Description formats,
> 
> here is disagree
> 
> there is harm and it is in term of energy of the WG and in
> term of the 
> effectiveness of a standard.
> 
> as people may have noticed, we do have a problem finding
> reviews for 
> some documents (other documents otoh, get plenty of
> reviews)
> So, i am concerned to disipate energy through multiple
> documents, and i 
> preffer to concentrate the enrgey in a single proposal
> 
> the other harm is that having two standards for the same
> function is 
> clearly less optimal than having only one, i guess people
> will not argue 
> against that
> 
> (i do understand that the path of less resistance is to get
> all the 
> solutions approved and published, but if we do that,
> standards are 
> meaningless, so i guess it is the chairs role to make that
> resistance)
> 
> So, my take in the general case, is that by default we make
> only one 
> standard for a given function
> 
> Which one, it is up to the WG to decide
> 
> regards, marcelo

      __________________________________________________________ 
Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 11:57:28 +0200

> that staying with one approach is in fact not always the obvious thing
I am not saying that we must define only one approach in all cases. What 
i am saying is that the default option is to define only one and we need 
strong reasons for do more than one

Regards, marcelo

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 16 Apr 2009 15:27:01 -0700 (PDT)

________________________________

From: marcelo bagnulo braun <[email-masked]>
To: Christian Kaas-Petersen <[email-masked]>
Cc: [email-masked]; mext <[email-masked]>
Sent: Wednesday, April 15, 2009 4:57:28 AM
Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules

My case in point will be Nemo PD. We have only one Nemo base protocol. But Nemo PD is a feature, it has been left out when the base protocol was defined. Defining two approaches to Nemo PD was already accepted in Nemo WG some time back. I don't understand why we don't do the same in Mext WG? In fact if you consider base protocol operations you will see that the protocol usually allows more than one option to be taken. Nemo PD can be viewed the same way allowing more than one option to be taken.
 
Regards,
 
Behcet

> that staying with one approach is in fact not always the obvious thing
I am not saying that we must define only one approach in all cases. What i am saying is that the default option is to define only one and we need strong reasons for do more than one

Regards, marcelo

[behcet] My idea in deciding one approach or second approach is that we should define only one base protocol. When it comes to feature extensions we may consider more than one solutions.