Subject: Re: [Bier] Comments on draft-ietf-bier-bier-yang

From: Xiejingrong <[email-masked]>
Date: Mon, 1 Apr 2019 10:10:18 +0000

Hi Chen Ran,

[Ran] "load-balance-number"?Do you means the maximum number of ECMP paths? OSPF YANG data model has defined it .In my opinion, it is neccesarry  to define this item here.

[XJR1]:
Yes I found the load-balance(max-ecmp) configuration in OSPF-yang and ISIS-yang, but I think they are different things, and there should be a load-balance-number for BIER specifically:

(1)     A BFR may not support BIER ECMP forwarding, while unicast ECMP is supported.

(2)     There may be different number of paths to different BFERs, for example BFER2/BFER2 may have 3/5 paths separately on a BFR, and this BFR may want a special load-balance-number 15 for better balancing.

[XJR2]:
Second question:
Is it allowed for both IPv4-encapsulation and IPv6-encapsulation being under a single Sub-domain ?

augment /rt:routing:
   +--rw bier
   |  +--rw bier-global
   |     +--rw sub-domain* [sub-domain-id]
   |        +--rw sub-domain-id            sub-domain-id
   |        +--rw underlay-protocol-type?  underlay-protocol-type
   |        +--rw mt-id?                    mt-id
   |        +--rw bfr-id?                   bfr-id
   |        +--rw bitstringlength?          bsl
   |        +--rw igp-algorithm?            ipa
   |        +--rw bier-algorithm?           bar
   |        +--rw af
   |           +--rw ipv4* [bitstringlength bier-mpls-label-base]
   |           |  +--rw bitstringlength               uint16
   |           |  +--rw bier-mpls-label-base          rt-types:mpls-label
   |           |  +--rw max-si?                       max-si
   |           +--rw ipv6* [bitstringlength bier-mpls-label-base]
   |              +--rw bitstrin+--glength            uint16
   |              +--rw bier-mpls-label-base          rt-types:mpls-label
   |              +--rw max-si?                       max-si
   |

The RFC8279 said, a BIER sub-domain must be associated with a single routing underlay (see below). I would understand IPv4 and IPv6 as different underlay.
   If multiple routing underlays are used in a single BIER domain, each
   BIER sub-domain MUST be associated with a single routing underlay
   (though multiple sub-domains may be associated with the same routing
   underlay).

[XJR3]:
Third question, maybe for the BIER WG.
It may also be helpful to discuss and conclude, if it is allowed for both BIER-MPLS encapsulation and BIER-Ethernet encapsulation being under a single sub-domain?
I feel it unnecessary since one can use different BIER Sub-domains carrying different encapsulations, and thus an MVPN service using BIER doesn’t have to specify the encapsulation-type.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 06, 2018 4:04 PM
To: Xiejingrong <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Re: [Bier] Comments on draft-ietf-bier-bier-yang

Hi jinrong，

Thanks for your review. Please see inline...

Regards.

Ran

原始邮件
发件人：Xiejingrong <[email-masked]<mailto:[email-masked]>>
收件人：BIER WG <[email-masked]<mailto:[email-masked]>>
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
日 期 ：2018年07月28日 21:01
主 题 ：Re: [Bier] Comments on draft-ietf-bier-bier-yang
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

some more comments:

1.  one sub-domain should allow miltiple {BSL and the according label block}s as encapsulations, see the igp sub-sub-TLV.

[Ran] We will add them ,and  will add the enternet and IPv6 encapsulation type.

2. should the igp-type change to underlay-protocol-type to allow bgp?

[Ran ]will add it.
From:Xiejingrong
To:BIER WG,
Cc:[email-masked],
Date:2018-07-28 20:36:25
Subject:[Bier] Comments on draft-ietf-bier-bier-yang

Hi folks,

I have the following comments and on draft-ietf-bier-bier-yang.
--should the bier load-balance-number/ipa/bar be added to rt:routing/bier-global/sub-domain (like below)? I think they are some basic items.
 [Ran] "load-balance-number"?Do you means the maximum number of ECMP paths? OSPF YANG data model has defined it .In my opinion, it is neccesarry  to define this item here.
 For the ipa/bar will be added to  rt:routing/bier-global/sub-domain.
augment /rt:routing:
   +--rw bier
   |  +--rw bier-global
   |     +--rw encapsulation-type?   identityref
   |     +--rw bitstringlength?      bsl
   |     +--rw bfr-id?               bfr-id
   |     +--rw ipv4-bfr-prefix?   inet:ipv4-prefix
   |     +--rw ipv6-bfr-prefix?   inet:ipv6-prefix
   |     +--rw sub-domain* [sub-domain-id]
   |        +--rw sub-domain-id      sub-domain-id
   |        +--rw igp-type?          igp-type
   |        +--rw mt-id?             mt-id
   |        +--rw bfr-id?            bfr-id
   |        +--rw bitstringlength?   bsl
   |        +--rw multi-bift-number? load-balance-number
   |        +--rw igp-algorithm?     ipa
   |        +--rw bier-algorithm?    bar

--should the bier-mpls-label-range-size be changed to ‘max si’ or not ? The type is uint8 and thus seems having to change the meaning.
 [Ran] Sure.

Thanks
Jingrong

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 15 Apr 2019 07:46:57 +0200

Dear Yang Authors,

1) I agree to Jingrong's comment that "Same sub-domain cannot be binded to
both IPv4 and IPv6 underlay". Pls refer the suggested model to handle this
at the end of the mail. Let me know your thoughts/comments.

2) About Jingrong's questions on "Whether same sub-domain can support
different encapsulation types like MPLS and Ethernet" ?
I would think - Yes, a single sub-domain can support many encapsulation
types. Architecturally it is possible that, for a sub-domain, each hop can
chose the encapsulation to be used based on next-hops capability. Yang
model should support it. However, we can discuss and clarify this.

3) A general request to BIER WG is that, we can discuss & progress the yang
work at better pace. Traditionally, yang standards progress slowly in IETF
resulting in implementation with private yang models :(

*Suggested BIER Yang Mode (sd is binded to either ipv4 or ipv6):*

   +--rw bier

   |  +--rw bier-global

   |     +--rw default-encapsulation-type?        identityref

   |     +--rw default-bitstringlength?           bsl

   |     +--rw default-bfr-id?                    bfr-id

   |     +--rw default-ipv4-bfr-prefix?           inet:ipv4-prefix

   |     +--rw default-ipv6-bfr-prefix?           inet:ipv6-prefix

   |     +--rw sub-domain* [sub-domain-id] [addr-family]

   |        +--rw addr-family            addr-family

   |        +--rw bfr-prefix?  inet:ipv4-ipv6-prefix

   |        +--rw mt-id?                   mt-id

   |        +--rw bfr-id?                  bfr-id

   |        +--rw bier-algorithm?          Bar

   |        +--rw load-balance-num         uint8

   |        +--rw encapsulation* [bitstringlength]

   |           +--rw bitstringlength               uint16

   |           +--rw encapsulation-type            enum

   |           +--rw max-si?                       rt-type: uint16

   |           +--rw bift-id-base?                 rt-types: bift-id

Thanks,
Senthil

On Mon, Apr 1, 2019 at 12:10 PM Xiejingrong <[email-masked]> wrote:

> Hi Chen Ran,
>
>
>
> [Ran] "load-balance-number"?Do you means the maximum number of ECMP paths?
> OSPF YANG data model has defined it .In my opinion, it is neccesarry  to
> define this item here.
>
>
>
> [XJR1]:
>
> Yes I found the load-balance(max-ecmp) configuration in OSPF-yang and
> ISIS-yang, but I think they are different things, and there should be a
> load-balance-number for BIER specifically:
>
> (2)     There may be different number of paths to different BFERs, for
> example BFER2/BFER2 may have 3/5 paths separately on a BFR, and this BFR
> may want a special load-balance-number 15 for better balancing.
>
>
>
> [XJR2]:
>
> Second question:
>
> The RFC8279 said, a BIER sub-domain must be associated with a single
> routing underlay (see below). I would understand IPv4 and IPv6 as different
> underlay.
>
> It may also be helpful to discuss and conclude, if it is allowed for both
> BIER-MPLS encapsulation and BIER-Ethernet encapsulation being under a
> single sub-domain?
>
> I feel it unnecessary since one can use different BIER Sub-domains
> carrying different encapsulations, and thus an MVPN service using BIER
> doesn’t have to specify the encapsulation-type.
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, September 06, 2018 4:04 PM
> *To:* Xiejingrong <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: Re: [Bier] Comments on draft-ietf-bier-bier-yang
>
>
>
> Hi jinrong，
>
> *发件人：*Xiejingrong <[email-masked]>
>
> *收件人：*BIER WG <[email-masked]>
>
> *抄送人：[email-masked] <
> [email-masked]>
>
> *日 期 ：*2018年07月28日 21:01
>
> *主 题 ：Re: [Bier] Comments on draft-ietf-bier-bier-yang*
>
> [email-masked]
> 1.  one sub-domain should allow miltiple {BSL and the according label
> block}s as encapsulations, see the igp sub-sub-TLV.
>
> *From:*Xiejingrong
> *To:*BIER WG,
> *Cc:[email-masked],
>
> *Date:*2018-07-28 20:36:25
>
> *Subject:*[Bier] Comments on draft-ietf-bier-bier-yang
>
>
>
> Hi folks,
>
>
>
> --should the bier load-balance-number/ipa/bar be added to
> rt:routing/bier-global/sub-domain (like below)? I think they are some basic
> items.
>
>  [Ran] "load-balance-number"?Do you means the maximum number of ECMP
> paths? OSPF YANG data model has defined it .In my opinion, it is neccesarry
>  to define this item here.
>
> --should the bier-mpls-label-range-size be changed to ‘max si’ or not ?
> The type is uint8 and thus seems having to change the meaning.
>
>  [Ran] Sure.
>
>
>
> Thanks
>
> Jingrong
>
>
>
>
> [email-masked]

---

From: <[email-masked]>
Date: Mon, 15 Apr 2019 14:30:49 +0800 (CST)

Hi Senthil, Jingrong,

Thank you for your review and comments.

I agree with your modification comments about the address-family.

About the encapsulation part:

Do you think if it's better to use both BSL and encapsulation-type as the keys?

About the load-balance-num, IMO it's not necessary to define it in BIER. 

BIER ECMP depends on IGP's ECMP capability. And as Jingrong said, there may be different ECMP path number in different routers.

So at most a ECMP enable capability can be showed in BIER model (sub-domain), it's not necessary to define the specific number.

Thanks,

Sandy

原始邮件

发件人：SenthilDhanaraj <[email-masked]>
收件人：Xiejingrong <[email-masked]>;
抄送人：陈然00080434;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年04月15日 13:45
主 题 ：Re: [Bier] Comments on draft-ietf-bier-bier-yang

Dear Yang Authors,
1) I agree to Jingrong's comment that "Same sub-domain cannot be binded to both IPv4 and IPv6 underlay". Pls refer the suggested model to handle this at the end of the mail. Let me know your thoughts/comments.

2) About Jingrong's questions on "Whether same sub-domain can support different encapsulation types like MPLS and Ethernet" ?
I would think - Yes, a single sub-domain can support many encapsulation types. Architecturally it is possible that, for a sub-domain, each hop can chose the encapsulation to be used based on next-hops capability. Yang model should support it. However, we can discuss and clarify this. 

3) A general request to BIER WG is that, we can discuss & progress the yang work at better pace. Traditionally, yang standards progress slowly in IETF resulting in implementation with private yang models :(

Suggested BIER Yang Mode (sd is binded to either ipv4 or ipv6):

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                   mt-id

   |        +--rw bfr-id?                  bfr-id

 
Thanks,Senthil

Hi Chen Ran,

 

[XJR1]:

 

[XJR2]:

Second question:

 

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                    mt-id

   |        +--rw bfr-id?                   bfr-id

   |        +--rw af

   |           |  +--rw max-si?                       max-si

   |              +--rw max-si?                       max-si

   |

   underlay).

[XJR3]:

 

 

Hi jinrong，

Regards.

Ran

原始邮件

发件人：Xiejingrong <[email-masked]>

收件人：BIER WG <[email-masked]>

抄送人：[email-masked] <[email-masked]>

日 期 ：2018年07月28日 21:01

some more comments:

[Ran ]will add it.

From:Xiejingrong

To:BIER WG,

Date:2018-07-28 20:36:25

 

Hi folks,

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |     +--rw bfr-id?               bfr-id

   |        +--rw mt-id?             mt-id

   |        +--rw bfr-id?            bfr-id

 

 [Ran] Sure.

Thanks

Jingrong

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 15 Apr 2019 09:12:19 +0200

Hi Sandy,

Thanks for the quick reply !
Pls check my comments inline !

-
Senthil

> I agree with your modification comments about the address-family.
Senthil//  Cool :)

> Do you think if it's better to use both BSL and encapsulation-type as the
Senthil// Yes. To allow a sub-domain to support many encapsulation-types,
both "encapsulation-type" and "bsl" should be key.

> BIER ECMP depends on IGP's ECMP capability. And as Jingrong said, there
> may be different ECMP path number in different routers.
>
> So at most a ECMP enable capability can be showed in BIER model
> (sub-domain), it's not necessary to define the specific number.
>
Senthil//  Multicast routing/forwarding tables and the forwarding procedure
itself requires more resources and is expensive compared to unicast
forwarding. So i'd prefer allowing the user to configure lesser ECMP number
for multicast compared to unicast.

Example, Unciast (ISIS/OSPF) ECMP=64, Multicast(BIER) ECMP=4.
So, even though there are 64 possible unicast ECMP paths, multicast would
only use the first 4 ECMP paths.

>
> Thanks,
>
> Sandy
>
>
> 原始邮件
> *发件人：*SenthilDhanaraj <[email-masked]>
> *收件人：*Xiejingrong <[email-masked]>;
> *抄送人：*陈然00080434;[email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>;
> *日 期 ：*2019年04月15日 13:45
> *主 题 ：**Re: [Bier] Comments on draft-ietf-bier-bier-yang*
> Dear Yang Authors,
> 3) A general request to BIER WG is that, we can discuss & progress the
> yang work at better pace. Traditionally, yang standards progress slowly in
> IETF resulting in implementation with private yang models :(
>
>> paths? OSPF YANG data model has defined it .In my opinion, it is
>> neccesarry   to define this item here.
>>
>>
>>
>> [XJR1]:
>>

---

From: Xiejingrong <[email-masked]>
Date: Mon, 15 Apr 2019 07:51:25 +0000

Hi Sandy,
Please see my comments below in-line:

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 15, 2019 2:31 PM
To: [email-masked]
Cc: Xiejingrong <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re:[Bier] Comments on draft-ietf-bier-bier-yang

Hi Senthil, Jingrong,

[xjr] thanks for having the same understanding about addr-family.

[xjr] There is description from rfc8401 section 6.2 that, a sub-sub-tlv with a specific bsl can be allowed only once within a sub-domain.

   If the same BitString length is repeated in multiple sub-sub-TLVs

   inside the same BIER Info sub-TLV, the BIER Info sub-TLV MUST be

   ignored.

This allow different BSLs with different encapsulation, as Senthil mentioned, but it may be more clean to use multiple sub-domains for different encapsulations, instead of using different encapsulations in a sub-domain.

[xjr] Are you talking about section 6.7.1 Non-deterministic ECMP of 8279 ?

I think section 6.7.2 Deterministic ECMP is more general, and in this case, the BIER ECMP number is the number of BIFT tables constructed for a sub-domain.

In this case, the BIER ECMP number is a configured number other than the default number <1>, which should be supported anyway (no matter what the ECMP paths to BFERs).

Thanks,

jingrong

Thanks,

Sandy

原始邮件
发件人：SenthilDhanaraj <[email-masked]<mailto:[email-masked]>>
收件人：Xiejingrong <[email-masked]<mailto:[email-masked]>>;
抄送人：陈然00080434;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;
日 期 ：2019年04月15日 13:45
主 题 ：Re: [Bier] Comments on draft-ietf-bier-bier-yang
Dear Yang Authors,
1) I agree to Jingrong's comment that "Same sub-domain cannot be binded to both IPv4 and IPv6 underlay". Pls refer the suggested model to handle this at the end of the mail. Let me know your thoughts/comments.

   +--rw bier
   |  +--rw bier-global

Thanks,
Senthil

On Mon, Apr 1, 2019 at 12:10 PM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chen Ran,

[XJR1]:

[XJR2]:
Second question:

augment /rt:routing:
   +--rw bier
   |  +--rw bier-global

[XJR3]:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 06, 2018 4:04 PM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Re: [Bier] Comments on draft-ietf-bier-bier-yang

Hi jinrong，

Regards.

Ran

原始邮件

some more comments:

[Ran ]will add it.
From:Xiejingrong
To:BIER WG,
Cc:[email-masked]<mailto:[email-masked]>,
Date:2018-07-28 20:36:25
Subject:[Bier] Comments on draft-ietf-bier-bier-yang

Hi folks,

Thanks
Jingrong

---

From: <[email-masked]>
Date: Mon, 15 Apr 2019 15:55:45 +0800 (CST)

Hi Senthil,

Thank you for your quick reply too! :-P

About the ECMP number, it is OK. Let's add a parameter for it because you insist on it. :-)

But seems like it is better to add the parameter in the underlay (OSPF and ISIS) configuration parts for comparing the value with max-ecmp easily.

How do you think about it?

Thanks,

Sandy

原始邮件

发件人：SenthilDhanaraj <[email-masked]>
收件人：张征00007940;
抄送人：Xiejingrong <[email-masked]>;陈然00080434;BIER WG <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年04月15日 15:11
主 题 ：Re: [Bier] Comments on draft-ietf-bier-bier-yang

Hi Sandy,

-
Senthil

Hi Senthil, Jingrong,

Senthil//  Cool :)

Senthil// Yes. To allow a sub-domain to support many encapsulation-types, both "encapsulation-type" and "bsl" should be key.

Senthil//  Multicast routing/forwarding tables and the forwarding procedure itself requires more resources and is expensive compared to unicast forwarding. So i'd prefer allowing the user to configure lesser ECMP number for multicast compared to unicast.

Example, Unciast (ISIS/OSPF) ECMP=64, Multicast(BIER) ECMP=4.
So, even though there are 64 possible unicast ECMP paths, multicast would only use the first 4 ECMP paths.

Thanks,

Sandy

原始邮件

Dear Yang Authors,

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                   mt-id

   |        +--rw bfr-id?                  bfr-id

 
Thanks,Senthil

Hi Chen Ran,

 

[XJR1]:

 

[XJR2]:

Second question:

 

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                    mt-id

   |        +--rw bfr-id?                   bfr-id

   |        +--rw af

   |           |  +--rw max-si?                       max-si

   |              +--rw max-si?                       max-si

   |

   underlay).

[XJR3]:

 

 

Hi jinrong，

Regards.

Ran

原始邮件

日 期 ：2018年07月28日 21:01

some more comments:

[Ran ]will add it.

From:Xiejingrong

To:BIER WG,

Date:2018-07-28 20:36:25

 

Hi folks,

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |     +--rw bfr-id?               bfr-id

   |        +--rw mt-id?             mt-id

   |        +--rw bfr-id?            bfr-id

 

 [Ran] Sure.

Thanks

Jingrong

---

From: <[email-masked]>
Date: Mon, 15 Apr 2019 16:07:41 +0800 (CST)

Hi Jingrong,

About the ECMP part, please see my previous email replied to Senthil.

About the restriction defined in RFC8401 section 6.2, IMO it only takes effect to the same encapsulation function, that is we need not advertise multiple mpls BIFT-ID for a BSL.

For different encapsulation function, the restriction should not take effect.

Thanks,

Sandy

原始邮件

发件人：Xiejingrong <[email-masked]>
收件人：张征00007940;[email-masked] <[email-masked]>;
抄送人：陈然00080434;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年04月15日 15:51
主 题 ：RE: Re:[Bier] Comments on draft-ietf-bier-bier-yang

Hi Sandy,

 

 

Hi Senthil, Jingrong,

   ignored.

Thanks,

jingrong

Thanks,

Sandy

原始邮件

日 期 ：2019年04月15日 13:45

Dear Yang Authors,

 

 

 

 

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                   mt-id

   |        +--rw bfr-id?                  bfr-id

 

Thanks,

Senthil

Hi Chen Ran,

 

[XJR1]:

 

[XJR2]:

Second question:

 

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                    mt-id

   |        +--rw bfr-id?                   bfr-id

   |        +--rw af

   |           |  +--rw max-si?                       max-si

   |              +--rw max-si?                       max-si

   |

   underlay).

[XJR3]:

 

 

Hi jinrong，

Regards.

Ran

原始邮件

日 期 ：2018年07月28日 21:01

some more comments:

[Ran ]will add it.

From:Xiejingrong

To:BIER WG,

Date:2018-07-28 20:36:25

 

Hi folks,

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |     +--rw bfr-id?               bfr-id

   |        +--rw mt-id?             mt-id

   |        +--rw bfr-id?            bfr-id

 

 [Ran] Sure.

Thanks

Jingrong

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 15 Apr 2019 11:28:22 +0200

Hi Sandy,

(1)
Its not appropriate to define the BIER ECMP parameter in ISIS/OSPF Yang.
Also, i do not think we need to compare/validate the Unicast and BIER ECMP
configuration.

Case-1: Unicast ECMP Config = BIER ECMP Config
Unicast ECMP = 4
BIER ECMP = 4

Case-2: Unicast ECMP  Config  > BIER ECMP Config
Unicast ECMP = 4
BIER ECMP = 2
BIER would use the first 2 unicast ECMP paths.

Case-2: Unicast ECMP  Config  < BIER ECMP Config
Unicast ECMP = 2
BIER ECMP = 4
BIER would use the 2 unicast ECMP paths for 4 BIFT tables.
Example, for a given bfr-id,
BIFT ECMP table-1 uses Unicast ECMP path1
BIFT ECMP table-2 uses Unicast ECMP path2
BIFT ECMP table-3 uses Unicast ECMP path1
BIFT ECMP table-4 uses Unicast ECMP path2

(2)
Remember, BIER might define its own SPF (or) constrained SPF, which is
different from IGP SPF.
In that case, BIER ECMP paths will be completely different to Unicast ECMP
Paths.

Thanks,
Senthil

On Mon, Apr 15, 2019 at 9:55 AM <[email-masked]> wrote:

> But seems like it is better to add the parameter in the underlay (OSPF and
> ISIS) configuration parts for comparing the value with max-ecmp easily.
>
> *收件人：*张征00007940;
> *抄送人：*Xiejingrong <[email-masked]>;陈然00080434;BIER WG <
> [email-masked]>;[email-masked] <
> [email-masked]>;
> *日 期 ：*2019年04月15日 15:11
> Senthil//  Multicast routing/forwarding tables and the forwarding
> procedure itself requires more resources and is expensive compared to
> unicast forwarding. So i'd prefer allowing the user to configure lesser
> ECMP number for multicast compared to unicast.
>
>> 1) I agree to Jingrong's comment that "Same sub-domain cannot be binded
>> to both IPv4 and IPv6 underlay". Pls refer the suggested model to handle
>> this at the end of the mail. Let me know your thoughts/comments.
>>
>>> It may also be helpful to discuss and conclude, if it is allowed for
>>> both BIER-MPLS encapsulation and BIER-Ethernet encapsulation being under a
>>> single  sub-domain?
>>>

---

From: <[email-masked]>
Date: Mon, 15 Apr 2019 17:40:55 +0800 (CST)

Hi Senthil,

Sorry for not saying it clearly!

I mean that we add the parameter in the BIER OSPF/ISIS YANG augment parts.

Like this:

  augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ospf:ospf:

   +--rw bier-ospf-cfg

      +--rw mt-id          mt-id

      +--rw bier-global

         +--rw enable?      boolean

         +--rw advertise?   boolean

         +--rw receive?     boolean

         +--rw ecmp-num?     boolean

Since we need not compare/vadidate the value with unicast, seems like it won't make great sense to define this parameter.

Thanks,

Sandy

原始邮件

日 期 ：2019年04月15日 17:27

Hi Sandy,

(1)
Its not appropriate to define the BIER ECMP parameter in ISIS/OSPF Yang.Also, i do not think we need to compare/validate the Unicast and BIER ECMP configuration.

 
(2)
Remember, BIER might define its own SPF (or) constrained SPF, which is different from IGP SPF.
In that case, BIER ECMP paths will be completely different to Unicast ECMP Paths.

Thanks,
Senthil

Hi Senthil,

Thanks,

Sandy

原始邮件

Hi Sandy,

-
Senthil

Hi Senthil, Jingrong,

Senthil//  Cool :)

Thanks,

Sandy

原始邮件

Dear Yang Authors,

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                   mt-id

   |        +--rw bfr-id?                  bfr-id

 
Thanks,Senthil

Hi Chen Ran,

 

[XJR1]:

 

[XJR2]:

Second question:

 

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |        +--rw mt-id?                    mt-id

   |        +--rw bfr-id?                   bfr-id

   |        +--rw af

   |           |  +--rw max-si?                       max-si

   |              +--rw max-si?                       max-si

   |

   underlay).

[XJR3]:

 

 

Hi jinrong，

Regards.

Ran

原始邮件

日 期 ：2018年07月28日 21:01

some more comments:

[Ran ]will add it.

From:Xiejingrong

To:BIER WG,

Date:2018-07-28 20:36:25

 

Hi folks,

augment /rt:routing:

   +--rw bier

   |  +--rw bier-global

   |     +--rw bfr-id?               bfr-id

   |        +--rw mt-id?             mt-id

   |        +--rw bfr-id?            bfr-id

 

 [Ran] Sure.

Thanks

Jingrong

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 15 Apr 2019 13:39:29 +0200

Hi Sandy,

Got you !
But, pls consider point 2 from my mail as well. That is,

       (2)
       Remember, BIER might define its own SPF (or) constrained SPF, which
is different from IGP SPF.
       *In that case, BIER ECMP paths (& the number of ECMP paths) will be
completely different from Unicast ECMP Paths.*

Example,
BAR=1 (means next-hop must be BIER capable, support same SD, support same
BSL ... So remove nodes which not satisfy this constraints from SPF tree)
or
BAR=X (A new multicast specific algorithm)

So considering both points - (1) & (2), i'd think its better we add a
separate "ECMP Configuration parameter" for BIER under BIER Yang. What do
you think ?

Thanks,
Senthil

On Mon, Apr 15, 2019 at 11:41 AM <[email-masked]> wrote:

>   augment
> /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ospf:ospf:
>
>    +--rw bier-ospf-cfg
>
>       +--rw mt-id          mt-id
>
>       +--rw bier-global
>
>          +--rw enable?      boolean
>
>          +--rw advertise?   boolean
>
>          +--rw receive?     boolean
>
>          +--rw ecmp-num?     boolean
>
>
> Since we need not compare/vadidate the value with unicast, seems like it
> won't make great sense to define this parameter.
>
>
> Thanks,
>
> Sandy
> 原始邮件
> *日 期 ：*2019年04月15日 17:27
>> But seems like it is better to add the parameter in the underlay (OSPF
>> and ISIS) configuration parts for comparing the value with max-ecmp easily.
>>

---

From: <[email-masked]>
Date: Mon, 15 Apr 2019 20:17:40 +0800 (CST)

Hi Senthil,As I said in previous mail, I agree with the ECMP capability can be defined in BIER model. But seems like the specific ECMP number doesn’t make great sense from my personal point of view. :-)Thanks,Sandy 发自我的zMail 

原始邮件

发件人:SenthilDhanaraj<[email-masked]>

收件人:张征00007940;

抄送人:Xiejingrong;陈然00080434;bier<[email-masked]>;[email-masked];

日期:2019-04-15 19:39:29

主题:Re: [Bier] Comments on draft-ietf-bier-bier-yang

 Hi Sandy,

Got you !

       (2)

Example,

Thanks,
Senthil

On Mon, Apr 15, 2019 at 11:41 AM <[email-masked]> wrote:

> I mean that we add the parameter in the BIER OSPF/ISIS YANG augment parts