Subject: Re: [Bier] [bier] comments on draft-hu-bier-bfd-03

From: <[email-masked]>
Date: Wed, 6 Mar 2019 11:14:59 +0800 (CST)

Hi Sandy,

Thanks for your inspired comments.  Please find my notes in-line tagged Quan>>

Regards,

Quan

Hi authors,

Thank you for your update! IMO using BFD technology in BIER is useful. 

But I have comments with some sections in this version(03):

1. Section 4.1, if the Target SI-Bitstring TLV is mandatory? 

From my understanding this draft is different with "draft-ietf-bier-ping". 

The function defined in this document "draft-hu-bier-bfd" is unidirectional. 

BFER need to know the liveness of BFIR in order to monitor the link between BFIR and BFER. 

BFER can get the information includes Sub-domain-id, BS Len. etc through the underlay protocols. 

So I don't understand the usage of target SI-Bitstring.

And because the Bitstring is different among different multicast flows. Which one should be taken? 

Quan>>As defined in "draft-ietf-bier-ping", in section 3.3.2,"The Target SI-BitString TLV carries the set of
BFER from which the Initiator expects the reply from." "The BitString field carries the set of BFR-IDs of BFER(s) 
that Initiator expects the response from." IMO, in BIER BFD, the usage of target SI-Bitstring is to carry 
the set of BFERs which the BFIR expects to establish the BFD session with. The BitString field carries 
the set of BFR-IDs of BFER(s) that BFIR expects to bootstap.
2, Section 4.2, why IGP extensions are used to advertise the discriminator? 

IMO only edge routers should know the discriminator of BFIR. 
Quan>>IGP extensions can be used to advertise the discriminator. The method is first proposed in RFC7883 
and RFC7884. I agree with you. Only the edge routers should know the discriminator of BFIR. So 
Only the espected BFERs will save the discriminator and use it in BFD session establishment.
Is it necessary for BFRs to know the discriminator? 
Quan>>Yes, it is necessary. As decribed in draft-ietf-bfd-multipoint-19, in section 5.6, "Unlike point-to-point BFD, 
Multipoint BFD provides a form of the discovery mechanism for tails to discover the head. " 

And what is the situation for BFRs to use the BFIR's discriminator? 

Quan>>As defined in draft-ietf-bfd-multipoint-19, in section 5.6, "Sessions on the tail MAY be established dynamically, 
based on the receipt of a Multipoint BFD Control packet from the head, and are of type MultipointTail. "
The BFERs will establish the BIER BFD session when BFIR's discriminator is the same with the discriminator 
carried in BFD Control packet.
If it is more suitable to advertise the discriminator by overlay protocols?

Quan>>Thanks for the suggestion. It can be detailed researched in further discussion.

Thanks,

Sandy

---

From: <[email-masked]>
Date: Wed, 6 Mar 2019 14:19:33 +0800 (CST)

Hi Quan,

Thank you for your response.
Please see my comments in line as Sandy2>>>

Thanks,
Sandy
------------------原始邮件------------------
发件人：熊泉00091065
收件人：张征00007940;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年03月06日 11:16
主 题 ：Re: [Bier] [bier] comments on draft-hu-bier-bfd-03
_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

Hi Sandy,

Regards,
Quan

Hi authors,  Thank you for your update! IMO using BFD technology in BIER is useful.   But I have comments with some sections in this version(03):   1. Section 4.1, if the Target SI-Bitstring TLV is mandatory?   From my understanding this draft is different with "draft-ietf-bier-ping".   The function defined in this document "draft-hu-bier-bfd" is unidirectional.   BFER need to know the liveness of BFIR in order to monitor the link between BFIR and BFER.   BFER can get the information includes Sub-domain-id, BS Len. etc through the underlay protocols.   So I don't understand the usage of target SI-Bitstring.  And because the Bitstring is different among different multicast flows. Which one should be taken? 

Sandy2>>> As you pointed out, in "draft-ietf-bier-ping", in section 3.3.2,"The Target SI-BitString TLV carries the set of BFER from which the Initiator expects the reply from." It's necessary for getting responds from BFERs in BIER Ping. And as you wrote in the last paragraph in section 1, "The BIER BFD only supports the unidirectional multicast." So BFIR MAY, but needn't get the reasponding from BFERs in BIER BFD. IMO the Target SI-BitString TLV should be optional.

2, Section 4.2, why IGP extensions are used to advertise the discriminator?   IMO only edge routers should know the discriminator of BFIR.

Sandy2>>> Sorry that I didn't say it clearly. I mean BFERs should get the discriminator, but the BFR (neither BFIR nor BFER ) needn't. 
I'd like to know what situation will BFR (neither BFIR nor BFER) use the discriminator.