Re: [Teas] Could you check if the latest OSPF extension draft for availability address your comments?

[Daniele Ceccarelli <[e-mail]>]

Hi Greg, 

I think that's acceptable, or if you prefer you might consider a positioning encoding, e.g.  the availability TLV MUST follow the Ethernet bandwidth profile TLV it refers to.

Which one is easier to implement? Maybe your proposal?

BR
Daniele

> -----Original Message-----
> From: Gregory Mirsky
> Sent: martedì 26 gennaio 2016 21:22
> To: Daniele Ceccarelli; Lou Berger; Yemin (Amy); CCAMP
> Cc: Longhao; D'Alessandro Alessandro Gerardo; TEAS WG; Shah, Himanshu
> Subject: RE: [Teas] Could you check if the latest OSPF extension draft for
> availability address your comments?
> 
> Dear Daniele, Lou, et. al,
> apologies for prolonged silence in the discussion.
> I agree that Option 2 offers more elegant solution but it would require
> change to Availability TLV for the case when Ethernet_TSPEC includes
> multiple Ethernet Bandwidth Profile TLVs. In such scenario, as I understand
> Section 4.1 of RFC 6003, each of the Ethernet Bandwidth Profile TLVs within
> the same Ethernet_TSPEC will have unique value in the Index field. If we add
> Index field to the Availability TLV, reference it to the Index field as described
> in the Section 4.1 and note that mapping between two types of TLVs
> established via the Index would that acceptable solution?
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: Daniele Ceccarelli
> Sent: Monday, January 18, 2016 4:47 AM
> To: Lou Berger; Yemin (Amy); CCAMP
> Cc: Gregory Mirsky; Longhao; D'Alessandro Alessandro Gerardo; TEAS WG;
> Shah, Himanshu
> Subject: RE: [Teas] Could you check if the latest OSPF extension draft for
> availability address your comments?
> 
> Lou, Amy,
> 
> Let me try to rephrase the 2 options:
> 
> Option 1) As actually proposed by the draft.
> 
> +     Ethernet Sender T-spec Object
> 	++  EXISTING  Ethernet bandwidth profile TLV (type 2)
> 	++  NEW Extended Ethernet bandwidth profile TLV (e.g. type 4 - used
> instead of type 2 when availability is needed)
> 		+++ NEW availability sub-TLV of the NEW Extended Ethernet
> bandwidth profile TLV
> 
> Option 2)
> 
> +     Ethernet Sender T-spec Object
> 	++  EXISTING  Ethernet bandwidth profile TLV (type 2)
> 	++ NEW availability TLV to be used in conjunction with the type2 TLV
> when needed.
> 
> 
> Since the Ethernet Sender T-SPEC object allows for carrying multiple TLVs I
> tend to agree with Lou. When no availability is requested only the Ethernet
> BW profile TLV will be included, otherwise both it and the new availability
> one.
> 
> BR
> Daniele
> 
> > -----Original Message-----
> > From: Teas [mailto:[e-mail]] On Behalf Of Lou Berger
> > Sent: venerdì 15 gennaio 2016 22:17
> > To: Yemin (Amy); CCAMP
> > Cc: Gregory Mirsky; Longhao; D'Alessandro Alessandro Gerardo; TEAS WG;
> > Shah, Himanshu
> > Subject: Re: [Teas] Could you check if the latest OSPF extension draft
> > for availability address your comments?
> >
> > Amy,
> >     I think we're left with one substantive discussion topic:
> >
> > >> 3) Approach
> > >>
> > >>    Given that there is really no difference between 3.1.1. and
> > >> RFC6003 Section 4.1, I suggest dropping the Extended Ethernet
> > >> Bandwidth Profile TLV (section 3.1.1) and just adding the
> > >> Availability sub-tlv as a a new Ethernet SENDER_TSPEC object TLV
> > >> type.  This also helps backwards compatibility.
> > >
> > > [Amy] I will reply 2) and 3) together. The availability comes with
> > > bandwidth together, for example, the request is (bandwidth =
> > > 200Mbps, availability = 99.99%).
> > >
> > > That’s why the Availability sub-tlv is defined as a sub-tlv under
> > > Ethernet Bandwidth Profile TLV.
> > >
> > > As the Ethernet Bandwidth Profile TLV defined in RFC6003 is not
> > > capable to carry sub-tlv, a new Extended Ethernet Bandwidth Profile
> > > TLV is defined. This was presented and discussed in IETF90.
> >
> > So we're discussing two options:
> >
> > Option 1) new TLV with new optional sub-TLV(s) + Availability sub-TLV
> > - New TLV : Extended Ethernet Bandwidth Profile TLV
> > https://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-bandwidth-availab
> > ility-
> > 03#section-3.1.1
> >
> > - NEW TLV = RFC6003 Section 4.1 + option sub-TLV(s) and  Availability
> > sub-TLV carried in new TLV, carried  when using availability,
> >
> > Option 2) Availability TLV
> > -No change to RFC 6003 or Ethernet Bandwidth Profile TLV
> > - Optional new Availability TLV carried when using availability
> >
> >
> > It seems to me that the carried information and the semantics are
> > equivalent.  But option 1 defines a strictly redundant information
> > format, with both added implementation and interoperability overhead.
> > So why not just go with option 2, i.e., drop section 3.1.1. and define
> > 3.1.2 as a tlv of the Ethernet SENDER_TSPEC object?
> >
> > Lou
> >
> >
> >
> >
> >
> >
> > On 1/13/2016 9:05 PM, Yemin (Amy) wrote:
> > >
> > > Dear all,
> > >
> > >
> > >
> > > Below is the offline discussion on
> > > “draft-ietf-ccamp-ospf-availability-extension-03” and
> > > “draft-ietf-ccamp-rsvp-te-bandwidth-availability-03”.
> > >
> > > You are welcome to give comments.
> > >
> > >
> > >
> > > BR,
> > >
> > > Amy
> > >
> > >
> > >
> > > *From:*Yemin (Amy)
> > > *Sent:* Wednesday, January 13, 2016 3:35 PM
> > > *To:* 'Lou Berger'
> > > *Cc:* D'Alessandro Alessandro Gerardo; Shah, Himanshu; Gregory
> > > Mirsky; Longhao
> > > *Subject:* RE: Could you check if the latest OSPF extension draft
> > > for availability address your comments?
> > >
> > >
> > >
> > > Hi Lou,
> > >
> > >
> > >
> > > Thanks for reply. Please see my reply starting with [Amy].
> > >
> > >
> > >
> > > BR,
> > >
> > > Amy
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Lou Berger [mailto:[e-mail]]
> > > Sent: Saturday, January 09, 2016 12:12 AM
> > > To: Yemin (Amy)
> > > Cc: D'Alessandro Alessandro Gerardo; Shah, Himanshu; Gregory Mirsky;
> > > Longhao
> > > Subject: Re: Could you check if the latest OSPF extension draft for
> > > availability address your comments?
> > >
> > >
> > >
> > > Hi Amy,
> > >
> > >
> > >
> > >
> > >
> > > On 12/29/2015 1:47 AM, Yemin (Amy) wrote:
> > >
> > > >
> > >
> > > > Hi Lou,
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > Could you kindly check if the latest OSPF extension draft for
> > >
> > > > availability address your comments?
> > >
> > > >
> > >
> > >
> > >
> > > Here are my original comments and their resolution:
> > >
> > > > On 7/25/2015 12:20 PM, Lou Berger wrote:
> > >
> > > > > Abstract: > - States applies to PSC >
> > >
> > > fixed .
> > >
> > >
> > >
> > > > > Sections 1 > - (general comment) informative sections such as
> > > > > Intro and Overview
> > >
> > > > > shouldn't contain normative (RFC2119) language. See >
> > >
> > > > http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some
> > > > >
> > >
> > > > suggested guidelines. >
> > >
> > > you still have a conformance statement in the abstract.  This is a
> > > nit
> > >
> > > and can be fixed whenever you do the next rev.
> > >
> > > [Amy] Thanks for pointing it out. Will fix it.
> > >
> > >
> > >
> > > > > Section 2 > - You mention "by the PE node" (and in two other
> > > > > places in the >
> > >
> > > > document). I have don't understand why "PE" is being introduced. >
> > >
> > > > Perhaps you mean simply "a node"? >
> > >
> > >
> > >
> > > done.
> > >
> > >
> > >
> > > > > Section 3.1 > - You duplicate a format definition from RFC4203.
> > > > > I think this
> > >
> > > > should > be replaced with a simple sentence stating that "The
> > >
> > > > Interface Switching > Capacity Descriptor (ISCD) sub-TLV is
> > > > defined in
> > >
> > > > Section 1.4 of [RFC 4203]". >
> > >
> > > done. as a nit comment you can get rid of section 3.1 and just move
> > > the
> > >
> > > reference to the first time you refer to ISCD
> > >
> > >
> > >
> > > > > - More significantly you are actually changing its format, and
> > > > > in
> > > > > >
> > > particular taking 8 bits from the existing reserved field: > > A
> > >
> > > > new AI field is defined in this document. >
> > >
> > > AI is gone, right?
> > >
> > > [Amy] Yes, AI is removed.
> > >
> > >
> > >
> > > > > - Taking bits from the reserved field is a major change and
> > > > > needs to be >
> > > justified. The purpose *and the use* of this new field,
> > >
> > > > Availability > Index, is unclear in the document. It needs to be,
> > > > or
> > >
> > > > better yet, drop it. > > Section 3.2: > - Why limit Availability
> > >
> > > > information to PSC and LSC? >
> > >
> > >
> > >
> > > This limitation remains.   I thought you agreed to dropping this in your
> > >
> > > mail back in August.
> > >
> > > [Amy] Sorry, I missed this point. Will fix it.
> > >
> > >
> > >
> > > > > Section 6.1 > - A number of references listed as Normative are
> > > > > not required to >
> > >
> > > > implement the mechanisms in the document and therefore should be >
> > >
> > > > identified as Informative.
> > >
> > >
> > >
> > > I think this needs some change, but this can be resolved
> > > independently
> > >
> > > of LC.
> > >
> > > [Amy] OK.
> > >
> > >
> > >
> > > > The attached is the mail discussion in July and Aug.We believe
> > > > that
> > >
> > > > the latest drafts addressed the comments in these mails, please check.
> > >
> > > >
> > >
> > > > The latest drafts links
> > >
> > > > arehttps://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availabi
> > > > li
> > > > ty-extension/,
> > >
> > > > and
> > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidt
> > > > h-
> > availability/.
> > >
> > > >
> > >
> > >
> > >
> > > My original comments were:
> > >
> > > > On 7/25/2015 12:20 PM, Lou Berger wrote:
> > >
> > > > > Hi, > I reviewed this document from the perspective of how
> > > > > generalized it
> > >
> > > > > is in its current form. > > I think this document's scope in
> > > > > it's
> > >
> > > > current form is limited to > RFC6003. I think it sould retitle the
> > >
> > > > draft to something like "Ethernet > Traffic Parameters With
> > >
> > > > Availability Information" to align with RFC6003.
> > >
> > > Done.
> > >
> > >
> > >
> > > > >  The document could also use RFC6003 as a 'design pattern' for
> > > > > some >
> > > reediting of its sections/text.
> > >
> > >
> > >
> > > So I guess this wasn't a sufficiently detailed comment.  I see
> > > several
> > >
> > > issues with section 3. In order of least to most significant:
> > >
> > > 1) Editorial nits:
> > >
> > >     There is no section 3.1
> > >
> > > There are grammar and spelling  errors in the section
> > >
> > > [Amy] Will fix it.
> > >
> > >
> > >
> > > 2) Formatting problems in sections 3.1.x
> > >
> > >     Type and length are included, when they aren't in RFC6003
> > > Section
> > > 4.1
> > >
> > >     Type isn't identified as needing to be assigned
> > >
> > >     Most fields lack definition
> > >
> > >     AF is defined as a redefinition of the Profile field rather than
> > >
> > > simply a definition
> > >
> > >         of a new bit in the field.  It should simply be an
> > > assignment of
> > >
> > > a new flag, i.e.:
> > >
> > >          Flag 3 (bit 1): Availability Flag (AF)
> > >
> > >     I also don't see the value of the flag as the rfc6003 already
> > >
> > > accommodates optional tlv inclusion and no explicit indication of
> > >
> > > subsequent TLVs is required.
> > >
> > >
> > >
> > > 3) Approach
> > >
> > >     Given that there is really no difference between 3.1.1. and
> > > RFC6003
> > >
> > > Section 4.1, I suggest dropping the Extended Ethernet Bandwidth
> > > Profile
> > >
> > > TLV (section 3.1.1) and just adding the Availability sub-tlv as a a
> > > new
> > >
> > > Ethernet SENDER_TSPEC object TLV type.  This also helps backwards
> > >
> > > compatibility.
> > >
> > > [Amy] I will reply 2) and 3) together. The availability comes with
> > > bandwidth together, for example, the request is (bandwidth =
> > > 200Mbps, availability = 99.99%).
> > >
> > > That’s why the Availability sub-tlv is defined as a sub-tlv under
> > > Ethernet Bandwidth Profile TLV.
> > >
> > > As the Ethernet Bandwidth Profile TLV defined in RFC6003 is not
> > > capable to carry sub-tlv, a new Extended Ethernet Bandwidth Profile
> > > TLV is defined. This was presented and discussed in IETF90.
> > >
> > >
> > >
> > > 4) Section 3.2
> > >
> > > This isn't needed, i.e., the section should be dropped,  as this is
> > >
> > > already provided for in RF6003 Section 5.
> > >
> > > [Amy] Ok.
> > >
> > >
> > >
> > > 5) Section 3.3
> > >
> > >
> > >
> > > This section should refer back to RFC6003 section 7 and  be modified
> > > to
> > >
> > > talk about the additional processing related to the Availability TLV
> > >
> > > (which shouldn't be a big change).
> > >
> > >
> > >
> > > You can drop the last paragraph as it is sufficiently covered in
> > > 6003,
> > >
> > > but you do need to mention what is expected to happen, as
> > > informative
> > >
> > > text, on a  node that doesn't support the new tlv.
> > >
> > > [Amy] Will update it.
> > >
> > >
> > >
> > > 6) The IANA section will need to be updated accordingly
> > >
> > >
> > >
> > >
> > >
> > > > > > I also suggest reviewing >
> > >
> > > > http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some
> > > > >
> > >
> > > > suggested guidelines.
> > >
> > >
> > >
> > >
> > >
> > > > If the drafts addressed all the comments, could it be moved forward?
> > >
> > > > Or if you have any other comments, just let us know.
> > >
> > > >
> > >
> > >
> > >
> > > So I think we're left with a minor comment + nits on the OSPF
> > > document
> > >
> > > and some more substantive work on the RSVP draft.
> > >
> > >
> > >
> > >
> > >
> > > >
> > >
> > > >
> > >
> > > > BTW, take this chance to wish a happy new year!
> > >
> > > >
> > >
> > >
> > >
> > > To you as well!
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Lou
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > BR,
> > >
> > > >
> > >
> > > > Amy(on behalf of the co-authors)
> > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas