Subject: Re: [Bier] IPA replace BAR - inconsistency across documents

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 29 May 2019 18:51:24 +0000

I finally got to update the draft as suggested below. Please see https://www.ietf.org/id/draft-ietf-bier-bar-ipa-04.txt.

@[email-masked] - Hope this go move forward now.

Thanks.
Jeffrey

Juniper Internal

> -----Original Message-----
> From: Senthil Dhanaraj <[email-masked]>
> Sent: Saturday, March 2, 2019 1:53 AM
> To: Loa Andersson <[email-masked]>; Jeffrey (Zhaohui) Zhang
> <[email-masked]>; Tony Przygienda <[email-masked]>
> Cc: [email-masked]; [email-masked]; benjamin r <[email-masked]>
> Subject: RE: [Bier] IPA replace BAR - inconsistency across documents
> 
> +1
> 
> Adding a text of below sorts to draft-ietf-bier-bar-ipa-03 should suffice.
> " The semantics for the BAR and IPA fields (when both or any of them is non-
> zero) defined in this document updates the semantics defined in
> RFC8444/RFC8401."
> 
> Note:
> Hereon, any new drafts defining the extensions for BIER (ex: BGP) shall point
> to draft-ietf-bier-bar-ipa-03 to explain the usage of BAR/IPA fields.
> 
> Thanks,
> Senthil
> 
> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: 02 March 2019 12:09
> To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Tony
> Przygienda <[email-masked]>
> Cc: [email-masked]; [email-masked]; benjamin r <[email-masked]>
> Subject: Re: [Bier] IPA replace BAR - inconsistency across documents
> 
> Jeffrey,
> 
> I think that an update of RFC8444/8401 is not "necessary".
> 
> That said, it would be very easy to do the update from the bar-ipa spec, just
> identify then that needs to be changed and tell how it should read.
> 
> /Loa
> 
> 
> On 2019-03-02 05:52, Jeffrey Zhaohui) Zhang wrote:
> > Hi Tony,
> >
> > I guess Benjamin’s point is that RFC8444/8401 used “replace” w/o the
> > “if the other value is 0”.
> >
> > I think we all (including Benjamin) agree that the bar-ipa spec is
> > crystal clear but Benjamin’s question is whether the RFC8444/8401
> > should change wording, and my thinking is there is no need.
> >
> > Thanks.
> > Jeffrey
> >
> > *From:*Tony Przygienda <[email-masked]>
> > *Sent:* Friday, March 1, 2019 2:31 PM
> > *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> > *Cc:* benjamin r <[email-masked]>; [email-masked];
> > [email-masked]
> > *Subject:* Re: IPA replace BAR - inconsistency across documents
> >
> > I thought that the language was clear enough to mean "replace if the
> > other value is 0", i.e. as long IGP algorithms are desired BAR=0 is
> > used, the moment special BIER metrics/computation types depending e.g.
> > on presence of subdomains and so on is needed, one would use BAR!=0 ...
> > What IPA!=0 would mean in such a case is to be defined for specific
> > use cases as far I remember the draft langugage. That seems all pretty
> > water-tight to me and all people involved were in agreement/had common
> > understanding as the author lists show ...
> >
> > --- tony
> >
> > On Fri, Mar 1, 2019 at 11:12 AM Jeffrey (Zhaohui) Zhang
> > <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Hi Benjamin,
> >
> >     I take it that you do agree that the language in
> >     draft-ietf-bier-bar-ipa is fine, just that it is somewhat
> >     conflicting with the existing wording in RFC8444/8401.
> >
> >     Since the bar-ipa draft is for the following purpose:
> >
> >         This document specifies general rules for interaction between
> >     the BAR
> >
> >         (BIER Algorithm) and IPA (IGP Algorithm) fields defined in
> > ISIS/
> >
> >         OSPFv2 Extensions for BIER.
> >
> >     I am thinking that we don’t need to explicitly update the wording in
> >     RFC8444/8401. Rather, marking this spec with “update RFC8444/8401”
> >     should be appropriate.
> >
> >     What do you think?
> >
> >     Thanks.
> >     Jeffrey
> >
> >     *From:* BIER <[email-masked] <mailto:[email-masked]>>
> >     *On Behalf Of *benjamin r
> >     *Sent:* Wednesday, February 27, 2019 5:46 AM
> >     *To:* [email-masked] <mailto:[email-masked]>
> >     *Subject:* [Bier] IPA replace BAR - inconsistency across documents
> >
> >     Hi All,
> >
> >     *draft-ietf-bier-bar-ipa-03*states “*If BA is not NULL, AG is set to
> >     BA.*”
> >
> >     This means, BAR take precedence over IPA.
> >
> >     This statement is conflicting with the OSPF/ISIS RFCs, which states
> >     IPA replaces path calculation defined by BAR value.
> >
> >     *Excerpts fromrfc8444 - S*ection 2.1.
> >
> >     IPA:Single-octet IGP Algorithm used to either modify, enhance, or
> >
> >     *replace* the *calculation* of underlay paths to reach other BFRs
> > as
> >
> >     *defined by the BAR value*.Values are defined in the "IGP
> >
> >     Algorithm Types" registry [IANA-IGP].
> >
> >     *Excerpts fromrfc8401 - *Section 6.1.
> >
> >     IPA: IGP Algorithm. Specifies an IGP Algorithm to either modify,
> >
> >     enhance, or *replace* the *calculation* of underlay paths to reach
> >
> >     BFERs as *defined by the BAR value*. Values are from the IGP
> >
> >     Algorithm registry. 1 octet.
> >
> >     To avoid confusions, can we update the texts in rfc8444 and rfc8401
> >     to align with draft-ietf-bier-bar-ipa-03 ?
> >
> >     Thanks
> >
> >     Benjamin R
> >
> >     VRP PDU, Network Business Line
> >
> >     Huawei Technologies India Pvt. Ltd.
> >
> >     Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
> >
> >     Bengaluru-560066, Karnataka
> >
> >     Tel: + 91-80-49160700 Ext II Mob: 8123906320 Email:
> >     [email-masked] <mailto:[email-masked]>
> >
> >     Company_logo
> >
> >
> > ----------------------------------------------------------------------
> > --
> >
> >     This e-mail and its attachments contain confidential information
> >     from HUAWEI, which
> >     is intended only for the person or entity whose address is listed
> >     above. Any use of the
> >     information contained herein in any way (including, but not limited
> >     to, total or partial
> >     disclosure, reproduction, or dissemination) by persons other than
> >     the intended
> >     recipient(s) is prohibited. If you receive this e-mail in error,
> >     please notify the sender by
> >     phone or email immediately and delete it!
> >
> >
> > _______________________________________________
> > BIER mailing list
> > [email-masked]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbf
> h0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=TgFskPhZ6Z8bnZ0zXuAsfYpYdOx6SmB4557t6dLjbSQ&s=CjdlZbeg9mMTML
> mDzyg9EUBve3C_CUhrdZPGig-q_CU&e=
> >
> 
> --
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbf
> h0UjBXeMK-
> ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=TgFskPhZ6Z8bnZ0zXuAsfYpYdOx6SmB4557t6dLjbSQ&s=CjdlZbeg9mMTML
> mDzyg9EUBve3C_CUhrdZPGig-q_CU&e=

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 29 May 2019 12:34:31 -0700

Please step forward and help participate in the IETF standards process, and
serve your WG members duty. :)

The process is simple and well documented. Just follow the steps and answer
the questions about the document.

Thanks,
Shep
(chairs)

On Wed, May 29, 2019 at 11:51 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> I finally got to update the draft as suggested below. Please see
> https://www.ietf.org/id/draft-ietf-bier-bar-ipa-04.txt.
>
> > >     *From:* BIER <[email-masked] <mailto:[email-masked]
> >>