Subject: [Bier] comments on the BIER ping draft

From: Antoni Przygienda <[email-masked]>
Date: Sat, 24 Oct 2015 06:55:30 +0000

3.3.6:  it's worth a discussion whether it's safer and more natural to return BFR-prefix here as advertised in IGP with the BIER attributes attached. I do think so.
3.3.7: why is this NOT following 3.3.4 format albeit referring to it. We will have unnumbered cases as well or not ?
4.1: where is the router alert? Is there a v6 frame within the BIER OAM frame or is a IPv6 encapsulation containing BIER presumed somehow ?
4,4 and 4.5 must be more specific about the bitmasks used to decide and the ones sent back in terms of processing, i.e. is the precise mask received used or the mask after processing (removing incoming bits, applying rules per e.g. -te- DNR bits and so on). Otherwise the bitmask interpretation may differ between receiver and sender and may lower significantly the usefulness of the  OAM procedures.

thanks

--- tony

We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
-Robert Wilensky

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 26 Oct 2015 18:28:25 +0000

HI Tony,

Thanks for the comments. Please see below..

<Nagendra>I think yes. BFR-Prefix will be advertised by all BFRs. We currently have "Routable Address" in the responding TLV. I think we can replace it with BFR-Prefix.

<Nagendra> The control plane information will help populate the egress interface and the downstream neighbor to which the packet is targetted which can be used to populate both Downstream Address and Downstream Interface Address. But Upstream Interface TLV only need to carry the incoming interface address.

You are right that we need to add support for unnumbered in 3.3.7. We will include the relevant Address type. Please let us know if this will help or if it needs more clarity by including the explanation on address format in 3.3.7.

<Nagendra>I am not sure which v6 frame you are referring. When the received label stack carries Router Alert label (label=1), it will punt for OAM processing.

<Nagendra> We tried differentiating the BitString before and after applying the forwarding rule by referring BitString in Header-H (before applying) and Egress BitString (after applying). I will check these sections to see if anything is misleading.

We will include the comments in next revision.

Thanks,
Nagendra

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 26 Oct 2015 18:31:58 +0000

[Tony saiz:] ack

[Tony saiz:] ack

<Nagendra>I am not sure which v6 frame you are referring. When the received label stack carries Router Alert label (label=1), it will punt for OAM processing.
[Tony saiz:] ah, ok, misunderstanding, my brain parsed router alert as IPv6 (2711) router alert and I forgot router alert label ;-)

<Nagendra> We tried differentiating the BitString before and after applying the forwarding rule by referring BitString in Header-H (before applying) and Egress BitString (after applying). I will check these sections to see if anything is misleading.
[Tony saiz:] thanks, you cannot be clear enough here from my experience with such specs

n  Tony