Re: [Bier] I-D Action: draft-ietf-bier-te-isis-01.txt

["Acee Lindem (acee)" <[e-mail]>]

On 8/3/22, 10:06 AM, "Les Ginsberg (ginsberg)" <ginsberg=[e-mail]> wrote:

    I tend to agree w Acee's comment.
    Two drafts seems excessive here.

Actually there are 3 (IS-IS, OSPF, OSPFv3), not even counting the inevitable BGP-LS draft. 

One point I made before on the cut and paste between drafts. In OSPF/OSPFv3, Sub-TLVs are referred to as Sub-TLVs no matter what their level of nesting. If we would have adopted the sub-sub....-TLV notation, we have many levels of nesting for the CCAMP TE LSAs for Optical technologies. 

Thanks,
Acee

    If the argument is that you want to keep the IS-IS  MPLS related stuff in a separate draft, I point out that RFC 8401 did NOT do that.

        Les

    > -----Original Message-----
    > From: BIER <[e-mail]> On Behalf Of Acee Lindem (acee)
    > Sent: Wednesday, August 3, 2022 4:10 AM
    > To: [e-mail]; [e-mail]
    > Cc: [e-mail]; ginsberg=[e-mail];
    > [e-mail]
    > Subject: Re: [Bier] I-D Action: draft-ietf-bier-te-isis-01.txt
    > 
    > Hi Sandy,
    > Why didn't you put all the IGP extensions in the same draft in different
    > sections? It is basically the same two Sub-TLVs with different IANA
    > considerations. When you consolidate, can you also add the BGP-LS
    > extension?
    > Thanks,
    > Acee
    > 
    > On 8/3/22, 4:11 AM, "BIER on behalf of [e-mail]" <bier-
    > [e-mail] on behalf of [e-mail]> wrote:
    > 
    >     Hi Toerless,
    >     The BIFT-ID advertisement as you said in the email, has been defined in
    > these drafts:
    >     https://datatracker.ietf.org/doc/draft-zwx-bier-te-isis-extensions/
    >     https://datatracker.ietf.org/doc/draft-zwx-bier-te-ospf-extensions/
    >     https://datatracker.ietf.org/doc/draft-zwx-bier-te-ospfv3-extensions/
    >     And these drafts was presented in IETF114 BIER WG meeting.
    >     Looking forward for your comments and suggestions.
    >     Best regards,
    >     Sandy
    > 
    >     ------------------Original------------------
    >     From: ToerlessEckert <[e-mail]>
    >     To: Huaimo Chen <[e-mail]>;
    >     Cc: Les Ginsberg (ginsberg)
    > <ginsberg=[e-mail]>;[e-mail] <[e-mail]>;
    >     Date: 2022年08月03日 12:05
    >     Subject: Re: [Bier] I-D Action: draft-ietf-bier-te-isis-01.txt
    >     Hey folks
    >     I am trying to wrap my head around how one would use these IS-IS
    > extensions for BIER-TE,
    >     and what if any of such semantic information might help the document...
    >     The way i assume this extension to be used is that some poor
    > system/operator assigns BIER-TE
    >     bits and configures the actual BIER-TE BIFT entries with forward_connected
    > entries to
    >     the neighbors. Similarily to how the same poor system/operator would
    > configure interface
    >     IP addresses on routers. This IS-IS work does not help to eliminate any of
    > this initial provisioning. [Yes/No]
    >     The way the IS-IS kicks in is to disseminate the information from those
    > forward_connected BIER-TE
    >     BIFT entries across the domain, so that for example ingres-PE could
    > calculate BIER-TE paths through the
    >     topology. [Yes/No].
    >     If i am on the right track, then let me continue:
    >     The first detail is that these IS-IS entries will seemingly have some
    > elements from rfc5303
    >     that identify the interface and/or neighbor. So those need to match what
    > would be found in
    >     the BIFT. I am not sure if it is obvious to every implementer how to achieve
    > that without
    >     additional guidance. For example i guess we ALSO need to have the IS-IS
    > signaling for the
    >     label ranges for the SD/SI in BIER. Have we checked thart we simply
    > should/can use them also
    >     for the SD that we use for BIER-TE ? I hope so, but i can not remember the
    > discussion.
    >     Likewise for BIER-TE over L2 (not MPLS), we have the dependency against
    > picking one particular
    >     bift-id encoding, and the "i don't know which" signaling we may have to
    > support it (could
    >     of course be all manual configured).
    >     Yes, this is just dependencies to make a deployment work, not necessarily
    > something an
    >     IGP specialist wants to see in an IGP draft/RFC, but i hope we can have this
    > more
    >     holistic discussion here ;-)
    >     So, then RFC5305 has all those wonderful adjacency parameters to help for
    > example ingres
    >     PE CSPF calculations. And i remember those from  RSVP-TE days. But now
    > the ISIS draft
    >     proposal introduces the BAR/IPA parameters, and i have never seen those
    > being mentioned
    >     or used in conjunction with TE in general or CSPF specifically. So it would be
    > great
    >     to have at least one example of how to use PAR/IPA be explained here. If
    > we can not
    >     construct such examples, then BIER/IPA may be leftovers from the IS-IS
    > encodings for
    >     BIER, where of course there is no CSPF and the like...
    >     Next question: Would it be possible to express with these IS-IS option the
    > forward_routed()
    >     I think it would be great if we would build the IS-IS extensions such that
    > that is possible,
    >     because forward_routed entries can be a great help to get along with the
    > available bits.
    >     I also would need to get my head around those IS-IS pseudonodes... if
    > anyone has an example,
    >     that would be great.
    >     Thanks so much!
    >     Toerless
    >     On Wed, Aug 03, 2022 at 02:58:53AM +0000, Huaimo Chen wrote:
    >     > Hi Les,
    >     >
    >     >     Thank you very much for your valuable comments.
    >     >     I have addressed them in the updated draft (uploaded).
    >     >     My responses are also inline below with [HC].
    >     >
    >     > Best Regards,
    >     > Huaimo
    >     > -----Original Message-----
    >     > From: BIER <[e-mail]> On Behalf Of Les Ginsberg
    > (ginsberg)
    >     > Sent: Friday, July 29, 2022 4:59 PM
    >     > To: [e-mail]
    >     > Subject: Re: [Bier] I-D Action: draft-ietf-bier-te-isis-01.txt
    >     >
    >     > Some pedantic comments on this draft:
    >     >
    >     > For the new BIER-TE sub-TLV:
    >     >
    >     > 1)The relevant registry has been renamed to be "IS-IS Sub-TLVs for TLVs
    > Advertising Neighbor Information". Please use this new name.
    >     >
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
    > w.iana.org%2Fassignments%2Fisis-tlv-codepoints%2Fisis-tlv-
    > codepoints.xhtml%23isis-tlv-codepoints-advertising-neighbor-
    > information&amp;data=05%7C01%7Chuaimo.chen%40futurewei.com%7C5b
    > bd38c256024261ea5608da71a546c0%7C0fee8ff2a3b240189c753a1d5591fedc%
    > 7C1%7C0%7C637947251926210034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
    > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
    > 0%7C%7C%7C&amp;sdata=ybC6zOJkG1sRe%2FQosV23MElysXHkg7jnHS70N
    > %2Bf7bpE%3D&amp;reserved=0
    >     > [HC]: I have renamed it as you suggested.
    >     >
    >     > 2)Please do NOT insert padding to keep content aligned on a 4 byte
    > boundary. This may be useful for OSPF, but it is not for IS-IS as TLVs are NOT
    > aligned inside an LSP. All you are doing is wasting space - which is precious in
    > IS-IS given the limited LSP space.
    >     > [HC]: Removed padding.
    >     >
    >     > 3)You say in Section 2:
    >     >
    >     > "Note that if each of BitPosition
    >     >    and DrEndBitPosition uses more than 2 octets, we use 4 or more octets
    >     >    for each of them."
    >     >
    >     > I do not see how the receiver of the sub-TLV could tell whether the 2
    > octet or 4 octet encoding was sent as you have nothing that specifies the
    > length of these fields.
    >     > You can't use the total length of the sub-TLV as it could include optional
    > sub-sub-TLVs.
    >     >
    >     > ??
    >     > [HC]: Deleted the quoted text.
    >     >
    >     > 4)In IANA section, I do not know why you specified "N" for TLVs 23 and
    > 223.
    >     > While RFC 5311 (which defines these TLVs) is not popular, if there was an
    > implementation, I see no reason why it should be invalid to send the BIER-TE
    > info in these TLVs.
    >     > [HC]: Changed "n" to "y" for TLVs 23 and 223.
    >     >
    >     > Thanx.
    >     >
    >     >     Les
    >     >
    >     >
    >     > > -----Original Message-----
    >     > > From: BIER <[e-mail]> On Behalf Of internet-
    > [e-mail]
    >     > > Sent: Friday, July 29, 2022 12:13 PM
    >     > > To: [e-mail]
    >     > > Cc: [e-mail]
    >     > > Subject: [Bier] I-D Action: draft-ietf-bier-te-isis-01.txt
    >     > >
    >     > >
    >     > > A New Internet-Draft is available from the on-line Internet-Drafts
    > directories.
    >     > > This draft is a work item of the Bit Indexed Explicit Replication WG of
    > the IETF.
    >     > >
    >     > >         Title           : IS-IS Extensions for BIER-TE
    >     > >         Authors         : Huaimo Chen
    >     > >                           Mike McBride
    >     > >                           Aijun Wang
    >     > >                           Gyan S. Mishra
    >     > >                           Yanhe Fan
    >     > >                           Lei Liu
    >     > >                           Xufeng Liu
    >     > >   Filename        : draft-ietf-bier-te-isis-01.txt
    >     > >   Pages           : 7
    >     > >   Date            : 2022-07-29
    >     > >
    >     > > Abstract:
    >     > >    This document describes IS-IS extensions for distributing
    >     > >    BitPositions configured on the links in "Bit Index Explicit
    >     > >    Replication Traffic Engineering" (BIER-TE) domain.
    >     > >
    >     > >
    >     > >
    >     > > The IETF datatracker status page for this draft is:
    >     > >
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
    > tracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-te-
    > isis%2F&amp;data=05%7C01%7Chuaimo.chen%40futurewei.com%7C5bbd38
    > c256024261ea5608da71a546c0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1
    > %7C0%7C637947251926210034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
    > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
    > 7C%7C%7C&amp;sdata=99ojCa2m%2BTeMk0OfxeifsmVrhvNaK7jQJp0fu0syR
    > N8%3D&amp;reserved=0
    >     > >
    >     > > There is also an htmlized version available at:
    >     > >
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
    > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bier-te-isis-
    > 01&amp;data=05%7C01%7Chuaimo.chen%40futurewei.com%7C5bbd38c256
    > 024261ea5608da71a546c0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
    > %7C637947251926210034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
    > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
    > %7C&amp;sdata=%2F8qaH0ZvQBAfGM4WIre0jpcI6As7wjXjdqbxOfdGHxo%3
    > D&amp;reserved=0
    >     > >
    >     > > A diff from the previous version is available at:
    >     > >
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
    > w.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-bier-te-isis-
    > 01&amp;data=05%7C01%7Chuaimo.chen%40futurewei.com%7C5bbd38c256
    > 024261ea5608da71a546c0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
    > %7C637947251926210034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
    > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
    > %7C&amp;sdata=L77o0dGWGuSwL9vSm1Durc56Fl5zONoDq%2F8ij12v9lc%3D
    > &amp;reserved=0
    >     > >
    >     > >
    >     > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-
    > drafts
    >     > >
    >     > >
    >     > > _______________________________________________
    >     > > BIER mailing list
    >     > > [e-mail]
    >     > >
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
    > w.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=05%7C01%7Chuaimo.c
    > hen%40futurewei.com%7C5bbd38c256024261ea5608da71a546c0%7C0fee8ff
    > 2a3b240189c753a1d5591fedc%7C1%7C0%7C637947251926210034%7CUnkno
    > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
    > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=em5K2lvVvXwkSl
    > ye1egSX%2BgtdfeqDArSsAycQJTPArI%3D&amp;reserved=0
    >     >
    >     > _______________________________________________
    >     > BIER mailing list
    >     > [e-mail]
    >     >
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
    > w.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=05%7C01%7Chuaimo.c
    > hen%40futurewei.com%7C5bbd38c256024261ea5608da71a546c0%7C0fee8ff
    > 2a3b240189c753a1d5591fedc%7C1%7C0%7C637947251926210034%7CUnkno
    > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
    > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=em5K2lvVvXwkSl
    > ye1egSX%2BgtdfeqDArSsAycQJTPArI%3D&amp;reserved=0
    >     >
    >     --
    >     ---
    >     [e-mail]
    >     _______________________________________________
    >     BIER mailing list
    >     [e-mail]
    >     https://www.ietf.org/mailman/listinfo/bier
    > 
    >     _______________________________________________
    >     BIER mailing list
    >     [e-mail]
    >     https://www.ietf.org/mailman/listinfo/bier
    > 
    > _______________________________________________
    > BIER mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/bier