Subject: [Bier] [BIER] New draft - ISIS Extensions for BIER in Non MPLS Networks // Fwd: New Version Notification for draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt

From: Senthil Dhanaraj <[email-masked]>
Date: Sat, 24 Nov 2018 12:59:09 +0530

Hi Folks,

Posted a new draft -  ISIS Extensions for BIER in Non-MPLS Networks .
Kindly read and provide your comments/Suggestions.

Note: For a quick look, you can refer the attached PPT instead as well.

Thanks,
Senthil

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Nov 23, 2018 at 11:21 PM
Subject: New Version Notification for
draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt
To: Jingrong Xie <[email-masked]>, Gang Yan <[email-masked]>,
Peter Psenak <[email-masked]>, IJsbrand Wijnands <[email-masked]>,
Senthil Dhanaraj <[email-masked]>

A new version of I-D, draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt
has been successfully submitted by Senthil Dhanaraj and posted to the
IETF repository.

Name:           draft-dhanaraj-bier-isis-non-mpls-extensions
Revision:       00
Title:          ISIS Extensions for BIER in Non-MPLS Networks
Document date:  2018-11-23
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dhanaraj-bier-isis-non-mpls-extensions/
Htmlized:
https://tools.ietf.org/html/draft-dhanaraj-bier-isis-non-mpls-extensions-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dhanaraj-bier-isis-non-mpls-extensions

Abstract:
   Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
   that provides multicast forwarding through a "BIER domain" without
   requiring intermediate routers to maintain multicast related per-flow
   state.  BIER can be supported in MPLS and non-MPLS networks.  The
   common BIER header format and encapsulation for MPLS and non-MPLS
   networks is specified in [RFC8296].

   BIER in Ethernet encapsulation is an example of BIER encapsulation in
   non-MPLS networks.

   [RFC8401] specifies the required extensions to the IS-IS [RFC1195]
   protocol for the distribution of BIER sub-domain information
   including the Sub-sub-TLV required to support BIER in MPLS
   encapsulation for MPLS networks.

   This document specifies the required extensions to the IS-IS
   [RFC1195] protocol for supporting BIER in non-MPLS networks using
   BIER in Ethernet encapsulation.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 30 Nov 2018 18:43:26 +0000

Hi Senthil,

I see that the posted draft is very different from a preview copy that we discussed, and the concept is the same as in section 3 and 4 of https://tools.ietf.org/html/draft-zzhang-bier-rift-00. An informational reference should be added.

Two questions/comments:

   Processing and forwarding of multicast packets using the BIER-ETH

   encapsulation requires special software and hardware capabilities.

   The BFRs supporting this encapsulation type MUST advertise this

   capability (along with the other required parameters specific to the

   encapsulation) to the other routers in BIER domain.

If static BIFT-ID assignment is used as in https://tools.ietf.org/html/draft-ietf-bier-non-mpls-bift-encoding-01, should we still advertise a BIER Info sub-TLV with Ethernet Encap sub-sub-TLV, perhaps with MaxSI and starting BIFT-ID all being 0? This is also a question for the authors of that draft.

   A BIER sub-domain MAY support multiple BIER encapsulation types like
   BIER-MPLS, BIER-ETH.  Within a BIER sub-domain, it is very well
   possible and allowable to share the same BFR-id for a BFR across
   different encapsulation types.  If the operator wishes to use
   different BFR-id for different encapsulation types, then he MUST
   provision different BIER sub-domain for each encapsulation type.

What’s the relevance/significance of the above text?

Additionally, do we expect/require interoperation of two encap types? I do believe it is reasonable for the two to work together, especially in that with signaled BIFT-IDs there is really no difference between the two. Perhaps some text can be added about that.

Instead of creating a parallel OSPF document, I think the document should just be expanded to cover OSPF as well.

Jeffrey

From: BIER <[email-masked]> On Behalf Of Senthil Dhanaraj
Sent: Saturday, November 24, 2018 2:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] [BIER] New draft - ISIS Extensions for BIER in Non MPLS Networks // Fwd: New Version Notification for draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt

Hi Folks,

Thanks,
Senthil

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Nov 23, 2018 at 11:21 PM
Subject: New Version Notification for draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt
To: Jingrong Xie <[email-masked]<mailto:[email-masked]>>, Gang Yan <[email-masked]<mailto:[email-masked]>>, Peter Psenak <[email-masked]<mailto:[email-masked]>>, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>, Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>>

Name:           draft-dhanaraj-bier-isis-non-mpls-extensions
Revision:       00
Title:          ISIS Extensions for BIER in Non-MPLS Networks
Document date:  2018-11-23
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions-2D00.txt&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=2QwuSp-sXW1jzMNRmKctGNfH3Tb4aMcTqaza8DitDE4&e=>
Status:         https://datatracker.ietf.org/doc/draft-dhanaraj-bier-isis-non-mpls-extensions/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=zc2X6pQd524aPxs9FZCR_urpmhYeBxFBNgsHvbomBPQ&e=>
Htmlized:       https://tools.ietf.org/html/draft-dhanaraj-bier-isis-non-mpls-extensions-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=9Zc1f3_64LJ7UBWL-UMbeE0claVu0cdCW09_t08Q80s&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dhanaraj-bier-isis-non-mpls-extensions<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=xe78vJSIC62C0F0PbkKKoZeMx9SEErHwhakBrTJBSco&e=>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=-a6a4ocjlV6FH4oyf5vmKjkgGIj3qQau0Dg7EJp-MpQ&e=>.

The IETF Secretariat

---

From: Senthil Dhanaraj <[email-masked]>
Date: Sat, 1 Dec 2018 10:58:20 +0530

Hi Jeffrey,

My Comments inline !

Thanks,
Senthil

On Sat, Dec 1, 2018 at 12:13 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi Senthil,
>
>
>
> I see that the posted draft is very different from a preview copy that we
> discussed, and the concept is the same as in section 3 and 4 of
> https://tools.ietf.org/html/draft-zzhang-bier-rift-00. An informational
> reference should be added.
>
Senthil // I guess the updated text for BIFT-ID is encoding is discussed &
shared, but perhaps the updated draft is not ! Yes, shall add reference to
the RIFT draft (DC Networks) which is in-fact a direct use case of BIER in
non-MPLS networks.

> If static BIFT-ID assignment is used as in
> https://tools.ietf.org/html/draft-ietf-bier-non-mpls-bift-encoding-01,
> should we still advertise a BIER Info sub-TLV with Ethernet Encap
> sub-sub-TLV, perhaps with MaxSI and starting BIFT-ID all being 0? This is
> also a question for the authors of that draft.
>

Senthil // Setting BIFT-ID to 0 (for Section 5 The Non-MPLS Static
BSL-SD-SI BIFT Encoding in
https://tools.ietf.org/html/draft-ietf-bier-non-mpls-bift-encoding-01) is
an option. But then, advertising the actual BIFT-ID comes at no additional
cost and might help in detecting badly or miss- configured BFRs in the
network.
-

> What’s the relevance/significance of the above text?
Senthil // Informational text to clarify that different encapsulation types
can share same BFR-ID and hence it is possible to support interop between
different encap types within same Sub-domain without requiring any-sort-of
bfr-id translation.

>
>
> Additionally, do we expect/require interoperation of two encap types? I
> do believe it is reasonable for the two to work together, especially in
> that with signaled BIFT-IDs there is really no difference between the two.
> Perhaps some text can be added about that.
>
Senthil // Yes, see above comment. Will update draft to make this clear.

> just be expanded to cover OSPF as well.
Senthil// Agreed. Will update same draft  with OSPFv2 extensions in the
next revision.

>
>
> Jeffrey
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Senthil Dhanaraj
> *Sent:* Saturday, November 24, 2018 2:29 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [Bier] [BIER] New draft - ISIS Extensions for BIER in Non MPLS
> Networks // Fwd: New Version Notification for
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions-2D00.txt&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=2QwuSp-sXW1jzMNRmKctGNfH3Tb4aMcTqaza8DitDE4&e=>
> Status:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=zc2X6pQd524aPxs9FZCR_urpmhYeBxFBNgsHvbomBPQ&e=>
> Htmlized:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=9Zc1f3_64LJ7UBWL-UMbeE0claVu0cdCW09_t08Q80s&e=>
> Htmlized:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Ddhanaraj-2Dbier-2Disis-2Dnon-2Dmpls-2Dextensions&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=xe78vJSIC62C0F0PbkKKoZeMx9SEErHwhakBrTJBSco&e=>
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=yxjAMEMhFznuXXpsmgGE3hu9aQivpClOliT7-8QGBhQ&s=-a6a4ocjlV6FH4oyf5vmKjkgGIj3qQau0Dg7EJp-MpQ&e=>
> .
>
> The IETF Secretariat
>