Subject: [Bier] FW: I-D Action: draft-kumarzheng-bier-ping-00.txt

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Fri, 6 Mar 2015 13:37:06 +0000

Hi BIER,

Below is the draft covering fault detection and isolation in BIER network.

Comments welcome.

Regards,
Nagendra (on behalf of authors)

On 3/6/15, 8:31 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>        Title           : BIER Ping and Trace
>        Authors         : Nagendra Kumar
>                          Carlos Pignataro
>                          Nobo Akiya
>                          Lianshu Zheng
>                          Mach Chen
>                          Greg Mirsky
>	Filename        : draft-kumarzheng-bier-ping-00.txt
>	Pages           : 20
>	Date            : 2015-03-06
>
>Abstract:
>   Bit Index Explicit Replication (BIER) is an architecture that
>   provides optimal multicast forwarding through a "BIER domain" without
>   requiring intermediate routers to maintain any multicast related per-
>   flow state.  BIER also does not require any explicit tree-building
>   protocol for its operation.  A multicast data packet enters a BIER
>   domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
>   BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
>   The BFIR router adds a BIER header to the packet.  The BIER header
>   contains a bit-string in which each bit represents exactly one BFER
>   to forward the packet to.  The set of BFERs to which the multicast
>   packet needs to be forwarded is expressed by setting the bits that
>   correspond to those routers in the BIER header.
>
>   This document describes the mechanism and basic BIER OAM packet
>   format that can be used to perform failure detection and isolation on
>   BIER data plane.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-kumarzheng-bier-ping/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-kumarzheng-bier-ping-00
>
>
>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.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 6 Mar 2015 11:39:58 -0800

Nagendra, thanks for the work, especially putting several companies on
short notice under same hat and getting some kind of working doc with a
suggestion. I'll comment over the weekend on the minutiae of the bits
involved.

How long a slot do you guys suggest for it?

On a wider note, I would expect in the slot a presentation of requirements
that drove such a document, the solution and expect a lively input on the
floor from the participants, especially carriers. OAM is a precondition for
a manageable carrier-grade service @ scale and they better take the
opportunity to comment and influence the work by extending necessary
requirements and comments. Especially since p2mp OAM is not what I hear
being a simple problem to attack

Thanks

--- tony

On Fri, Mar 6, 2015 at 5:37 AM, Nagendra Kumar Nainar (naikumar) <
[email-masked]> wrote:

> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 6 Mar 2015 11:41:32 -0800

Inline:

> being a simple problem to attack
I agree. I think we should start with a wider OAM reqs presentation before
solutions to get everyone close to the same page.

Greg

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Fri, 6 Mar 2015 19:55:06 +0000

Hi Tony,

<Nagendra> I think a 30 minutes slot should be fine. We will share the PPT and presenter info soon.

On a wider note, I would expect in the slot a presentation of requirements that drove such a document, the solution and expect a lively input on the floor from the participants, especially carriers. OAM is a precondition for a manageable carrier-grade service @ scale and they better take the opportunity to comment and influence the work by extending necessary requirements and comments. Especially since p2mp OAM is not what I hear being a simple problem to attack

<Nagendra> Yes. That infact is the plan and consensus among the authors as well. We will discuss about the considerations and requirement for this machinery during the presentation.

Thanks,
Nagendra

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 6, 2015 at 2:39 PM
To: Nagendra Kumar Nainar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Mach Chen <[email-masked]<mailto:[email-masked]>>, Nobo Akiya <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] FW: I-D Action: draft-kumarzheng-bier-ping-00.txt

Nagendra, thanks for the work, especially putting several companies on short notice under same hat and getting some kind of working doc with a suggestion. I'll comment over the weekend on the minutiae of the bits involved.

On a wider note, I would expect in the slot a presentation of requirements that drove such a document, the solution and expect a lively input on the floor from the participants, especially carriers. OAM is a precondition for a manageable carrier-grade service @ scale and they better take the opportunity to comment and influence the work by extending necessary requirements and comments. Especially since p2mp OAM is not what I hear being a simple problem to attack

Thanks

--- tony

On Fri, Mar 6, 2015 at 5:37 AM, Nagendra Kumar Nainar (naikumar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi BIER,

Comments welcome.

Regards,

On 3/6/15, 8:31 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
wrote:

>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 8 Mar 2015 07:44:42 +0000

As individual cat meowing ;-)  ::

OK, read through the draft and here's a bunch of observations @ different levels:

a)      To verify my understanding first:

i)       it looks like the answer can be given in-band (via BIER which will verify bi-directional continuity) or out-band (via BIER) while the request is always in-band (which makes sense).

a.      Which address is used when replying UDP then? The sender's handle does not carry IPv4 address semantics and the OAM packet is not IP. The most likely candidate is upstream interface TLV but it says specifically that it's the replhying BFR that sets it.

j)       It looks like there are no provisions in the OAM currently for anything but straight ping carrying additionally the mask @ the node  (i.e. not throughput, loss ratios, alarms and so on)

b)      As first SI-BS TLVs:

i)       Bistring Len of a byte is not described further and assuming it's to be interpreted as one-byte unsigned int, this won't work. Even if becomes 2 bytes, to prevent things like bitstring len = 11 being advertised in the original SI-BS TLV I suggest to follow the 4 bits encoding used in MPLS draft (which I think should be moved to the architecture draft and probably extended to arbitrary number of bits  by the means of a simple formula [which MPLS encaps draft uses]

32 * 2 ^ (len field value interpreted as unsigned int)

)

ii)  given we can reply out-of-band (i.e. without any labels or following the BIER sub-domain but using IP substrate) I do not think that the SI-BS TLVs can get away without carrying sub-domains. Set ID and BFR-ID are specific both to a BIER domain and sub-domain so they can be confused. The domain can be distinguished by the loopback. I do not expect people provisioning loopback per sub-domain and in fact the IGP drafts today are not intended to do so [the BGP won't allow it assuming a single BIER-prefix]). I would consider relying on 'sender's handle'-matching to disassociate subdomain/set architecturally sub-optimal.

c)      I see that the responder BFR TLV allows for BFRs without BFR-ids to respond but  I fail to see how they are triggered to do so since it is the target SI-BS TLV which describes the necessary responders and that carries a bitstring only which relies on BFR-ids being assigned

Thanks

--- tony

---

There are basically two types of people. People who accomplish things, and people

who claim to have accomplished things. The first group is less crowded.

                                                                                          ~~~ Mark Twain

> -----Original Message-----

> From: BIER [mailto:[email-masked]] On Behalf Of Nagendra Kumar

> Nainar (naikumar)

> Sent: Friday, March 06, 2015 5:37 AM

> To: [email-masked]

> Cc: Gregory Mirsky; Carlos Pignataro (cpignata); Mach Chen; Nobo Akiya;

> [email-masked]

> Subject: [Bier] FW: I-D Action: draft-kumarzheng-bier-ping-00.txt

> >submission until the htmlized version and diff are available at

> >tools.ietf.org.

> >Internet-Draft directories: http://www.ietf.org/shadow.html or

> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 10 Mar 2015 17:08:01 +0000

Hi Tony,

Thanks for your time and comments. Please see inline…

<Nagendra> The packet format is flexible to be used for both in-band and out-band. But the request is not necessarily to be always in-band.

a.      Which address is used when replying UDP then? The sender’s handle does not carry IPv4 address semantics and the OAM packet is not IP. The most likely candidate is upstream interface TLV but it says specifically that it’s the replhying BFR that sets it.

<Nagendra> Thanks for bringing this up. We have not included the IP based reply in this revision of the document. One option that we thought and discussed initially is around the use of BFIR ID from the OAM packet and get the associated BFR-Prefix from local IGP database. The other option is to include a TLV carrying the address of originator to be used for reply (like Reply-to address) :)

<Nagendra> The primary focus of this document is to get the fault detection and isolation. So we have not included the performance measurement in this document. Greg raised this point already and we thought it is better to have a different document covering it.

b)      As first SI-BS TLVs:

)

<Nagendra>Yes, the intention was to follow the encapsulation draft definition and interpretation. While we already referred the encapsulation draft for interpretation, I think it makes sense to make it as 4 bits size as in encapsulation draft. I will change this.

ii)  given we can reply out-of-band (i.e. without any labels or following the BIER sub-domain but using IP substrate) I do not think that the SI-BS TLVs can get away without carrying sub-domains. Set ID and BFR-ID are specific both to a BIER domain and sub-domain so they can be confused. The domain can be distinguished by the loopback. I do not expect people provisioning loopback per sub-domain and in fact the IGP drafts today are not intended to do so [the BGP won’t allow it assuming a single BIER-prefix]). I would consider relying on ‘sender’s handle’-matching to disassociate subdomain/set architecturally sub-optimal.

<Nagendra>Can you clarify if this comment is regarding sending the reply or receiving the reply?. Did you meant that the TLV doesn’t have Sub-domain id and any deviation (due to some failure) may not be able to detect with SI and BFR-ID?. If so, I think, this needs a bit of clarity in the document. We will include the same. If my assumption on your query is wrong, please let me know.

 <Nagendra> The use of Target SI-BS TLV is optional for ping and is used to control the responding BFERs. A transit node will use it only for entropy calculation towards the BFER in Target SI-BS TLV.

Once again, thanks a lot for your comments.

Regards,
Nagendra

Thanks

--- tony

---

                                                                                          ~~~ Mark Twain

> To: [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 10 Mar 2015 17:24:17 +0000

Nagendra,

To verify my understanding first:

<Nagendra> The packet format is flexible to be used for both in-band and out-band. But the request is not necessarily to be always in-band.
[Tony saiz:] Then I didn't see how you can send a request 'out-of-band', i.e. not by means of BIER.  The OAM is carrier on a BIER protocol field so it looks to me it's carried in-band-on BIER (which makes sense). Unless you mean that I can OAM a subdomain via BIER'ing OAM via another sub-domain (such as we have a management topology in MT). Seems unlikely to me.

a.      Which address is used when replying UDP then? The sender's handle does not carry IPv4 address semantics and the OAM packet is not IP. The most likely candidate is upstream interface TLV but it says specifically that it's the replhying BFR that sets it.
<Nagendra> Thanks for bringing this up. We have not included the IP based reply in this revision of the document. One option that we thought and discussed initially is around the use of BFIR ID from the OAM packet and get the associated BFR-Prefix from local IGP database. The other option is to include a TLV carrying the address of originator to be used for reply (like Reply-to address) :)
[Tony saiz:] I think IGP tying it together is fine for the moment. That's how the whole architecture is put together. There will be always a prefix to BFR-id association. As subtle note, we're putting the requirement here that the prefix is routable but that seems fair. At least in IGP it's carried in TLVs that compute reachable routes.

<Nagendra> The primary focus of this document is to get the fault detection and isolation. So we have not included the performance measurement in this document. Greg raised this point already and we thought it is better to have a different document covering it.
[Tony saiz:] OK, my observation would be then that we need ideally a packet format to accommodate future OAM directions without putting it into another BIER protocol.

a)      As first SI-BS TLVs:

)

[Tony saiz:] thanks.

<Nagendra>Can you clarify if this comment is regarding sending the reply or receiving the reply?. Did you meant that the TLV doesn't have Sub-domain id and any deviation (due to some failure) may not be able to detect with SI and BFR-ID?. If so, I think, this needs a bit of clarity in the document. We will include the same. If my assumption on your query is wrong, please let me know.
[Tony saiz:] Yes, I meant that you will not be able necessarily to derive subdomain-id from the response as far I see the packet formats. If you e.g. carry labels, those may have changed in the meantime.  A single prefix can have many sub-domains under it per architecture & IGP drafts.

b)      I see that the responder BFR TLV allows for BFRs without BFR-ids to respond but  I fail to see how they are triggered to do so since it is the target SI-BS TLV which describes the necessary responders and that carries a bitstring only which relies on BFR-ids being assigned

[Tony saiz:] oh, ok, need to scratch my head over it.

Overall, the document is reach in packet formats and a little lean on the procedures section ;-)

--- tony

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 10 Mar 2015 23:51:51 +0000

Hi Tony,

Nagendra,

<Nagendra> The packet format is flexible to be used for both in-band and out-band. But the request is not necessarily to be always in-band.
[Tony saiz:] Then I didn’t see how you can send a request ‘out-of-band’, i.e. not by means of BIER.  The OAM is carrier on a BIER protocol field so it looks to me it’s carried in-band-on BIER (which makes sense). Unless you mean that I can OAM a subdomain via BIER’ing OAM via another sub-domain (such as we have a management topology in MT). Seems unlikely to me.

<Nagendra2> ah. Ok.  By in-band and out-band,you meant - with BIER protocol :). I misunderstood it as in band to data traffic. Yes. That is right.

a.      Which address is used when replying UDP then? The sender’s handle does not carry IPv4 address semantics and the OAM packet is not IP. The most likely candidate is upstream interface TLV but it says specifically that it’s the replhying BFR that sets it.
<Nagendra> Thanks for bringing this up. We have not included the IP based reply in this revision of the document. One option that we thought and discussed initially is around the use of BFIR ID from the OAM packet and get the associated BFR-Prefix from local IGP database. The other option is to include a TLV carrying the address of originator to be used for reply (like Reply-to address) :)
[Tony saiz:] I think IGP tying it together is fine for the moment. That’s how the whole architecture is put together. There will be always a prefix to BFR-id association. As subtle note, we’re putting the requirement here that the prefix is routable but that seems fair. At least in IGP it’s carried in TLVs that compute reachable routes.

<Nagendra2> Ok. We are considering both the options for discussion. Future revision will be updated with this information.

<Nagendra2> This is one of the consideration we had in mind while discussion on the format. The OAM packet format is TLV based and depending on the message type (that can be for CC CV, PM etc), the TLV format can be defined (fixed or variable).

a)      As first SI-BS TLVs:

)

<Nagendra2> ok. We will include this.

<Nagendra2> Thanks. It will be updated :)

Regards,
Nagendra

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 11 Mar 2015 10:55:10 -0400

I have a few questions and comments.

First, thanks for not calling it "bier-pong" ;-)

Any TLV that has a BitString and an SI also has to have a sub-domain id, 
or else the set of BFERs identified in the BitString cannot be 
determined (nor can the BFIR).

I don't understand why it makes sense to use the BIER data plane to 
respond to a ping or traceroute.  I'd think you'd want to avoid BIER in 
the reverse direction, and use ICMP to send back the responses.  This 
would mean that the request needs to have the IP address to which to 
respond.  (If you do use BIER for the responses, you'd certainly need to 
know the sub-domain in which to interpret the BFIR, and you'd need to 
know the sub-domain to choose the right BIER-MPLS label.)

Overall, I agree with Tony that the draft would benefit from a lot more 
attention to procedures -- the document really doesn't make clear just 
how you put together the set of TLVs to actually do a traceroute (or 
even a ping).  Until it's clear just what information needs to be 
carried forwards and back, there's no point in discussing TLV formats.

For the traceroute case, the draft also needs to address the issue of 
how the initiator should collate the replies to figure out what path 
actually gets followed by a given data packet.

If a user says, "I'm getting spotty service when I try to receive a 
given data stream", how would one use these mechanisms to troubleshoot?

If you wanted to troubleshoot a problems with a particular user data 
stream, I think you'd need to know the entropy value of the data packets 
in the troublesome data stream.  You'd want to specify the entropy and 
find out what path is followed by packets to a given BFER (or set of 
BFERs) with that entropy value.  To enable this, the BitString TLVs 
would need to have an entropy value.  The draft doesn't seem to have any 
provision for that.  (And unless deterministic ECMP is used, I'm not 
sure this is a tractable problem at all.)

For traceroute, I guess the request sent by the initiator would be 
carried unchanged until there's a TTL expiry.  I think the request needs 
to carry the original BIER header (augmented with SI and sub-domain); 
this would be sent back in the response, along with the corresponding 
information that is in the BIER header when the request is received by 
the responder.  This would tell you which BFERs from the original 
BitString are in the sub-tree of the responder.  (The document does have 
a TLV for this.)

The draft seems to be trying to have the mechanisms discover all 
possible ECMP paths that a packet might take, but I don't really see how 
that is going to work in a scalable manner.  Also, I don't understand 
the proposed use of the "Multipath Entropy TLV".  What value gets put in 
it, and under what circumstances?

I don't really understand the Upstream Interface and Downstream Mapping 
TLVs.  If these are supposed to identify BIER adjacencies, then they 
need to take account of the fact that a pair of adjacent BFRs might be 
separated by an IP or MPLS tunnel, rather than being directly connected. 
  Or are these TLVs supposed to identify IGP adjacencies rather than 
BIER adjacencies?  What exactly is the intended function of these TLVs, 
and will they fulfill that function when the adjacenct BFRs are not 
directly connected?

With regard to traceroute, have you considered the impact of the 
"uniform model" for TTL handling (see RFC 3443)?  It may not always be 
possible to ensure that the TTL in the BIER-MPLS label is decremented 
only by the number of BFR hops.  In such a case, once a request has 
reached a particular BFR, the initiator might have to increment TTL 
several times to get a request to reach the next BFR hops.  This is 
something that needs to be discussed in a specification of the 
traceroute procedures.  It's also worth thinking about what would happen 
if a BIER OAM packet experiences TTL expiry while in the middle of a 
unicast tunnel.

The request has a "sequence number" that is supposed to be used to 
detect missing responses.  I don't see how that will work, since a 
single request in general elicits multiple responses.  You wouldn't be 
able to use the sequence number to detect missing responses unless all 
responses to the request with that sequence number were missing.

It might make sense though for the sequence number to be the same as the 
original TTL placed in the BIER-MPLS label by the initiator of the 
request.

The return codes are not very well-defined, and it's not clear just what 
the principles are that led to choosing that particular set of return 
codes.  It would be good to see some discussion of what information it 
is useful to return in various troubleshooting scenarios.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Fri, 13 Mar 2015 00:21:02 +0000

Hi Eric,

Thanks for the excellent comments. Please see below,

>First, thanks for not calling it "bier-pong" ;-)

<Nagendra> LOL :). When I tried to locate the draft using ³bier + ping² in
google, it pops a messages that an unusual search and asked me to confirm
that I am human and not machine :)
 
>determined (nor can the BFIR).

<Nagendra> Yes, I agree. We will include sub-domain id in the TLVs.

>the reverse direction, and use ICMP to send back the responses.

<Nagendra> We considered both. You are right that we don¹t validate
anything in the reverse direction and can be IP based reply.

>This 

<Nagendra> By including the sub-domain in the TLV, we can use the BFIR id
to fetch the BFR-Prefi form IGP database. But I think, it will be more
clean to have a TLV carrying the ³Reply-to² address which will more
control to instruct what address to reply to.

>carried forwards and back, there's no point in discussing TLV formats.

<Nagendra> Sure. We will detail the procedure in next revision.

>actually gets followed by a given data packet.

<Nagendra> The current draft proposes TLVs to carry in Reply that includes
- incoming interface, incoming BitString (in the header) and also
downstream neighbors to which the reply was sent, along with egress
BitString that will be sent to each downstream neighbor. IMHO, Initiator
will be able to use these information (along with sender handler) to
portrait end to end path. How it portrait the path would be a local
matter, I think. We will include a point in the procedure and mention it
as local matter. 

Do you think something is missing from the Initiator point of view that
needs to be clarified?.

>given data stream", how would one use these mechanisms to troubleshoot?

<Nagendra> Ok. I think the procedure section (after updating) will be more
generic. Do you think, it is reasonable to add an Appendix section to give
a couple of such examples from usage point of view?.

>sure this is a tractable problem at all.)

<Nagendra> I think, we can achieve this in 2 ways. One option is to have
the Initiator (assuming that is also acting as the ingress for the actual
data stream) to use the same Entropy value (that will be used in the data
traffic) in probe packet. By this, we don¹t need to query each transit
BFRs. The other option is to query each BFR along the path about entropy
range for each ECMP path. This query does not need to carry any data
stream details as the entropy query is not specific to stream instead the
path that will be selected within a range. This is analogous to ECMP tree
trace in MPLS LSP Ping.

>BitString are in the sub-tree of the responder.  (The document does have

<Nagendra> Yes.
>that is going to work in a scalable manner.

<Nagendra> The primary intention is to have a way to perform ECMP query
per BFER. To troubleshoot a failure to a specific BFER or set of BFERs
should be possible by querying (and using) ECMP paths for one of the
affected BFER and use the entropy.

>Also, I don't understand

<Nagendra> This is similar to section 3.3.1 of RFC4379. To avoid redundant
information, we tried referring to RFC4379 (noticed that section info is
not given). Will it be helpful to have an example in Appendix?.

>TLVs. 

<Nagendra> Upstream Interface TLV is used by the responder to define the
incoming interface of the probe packet. This is useful to detect any
deviation in HW/distributed forwarding. Per BFR-A control-plane, Bit-id 10
is reachable via interface-A  while the data plane have a stale entry
pointing towards Interface-B. In this case, the reply from BFR-A will have
downstream address which does not match with upstream interface TLV of
next response. 

> If these are supposed to identify BIER adjacencies, then they

<Nagendra> Good point about the IP/MPLS tunnel :).The intention is to
carry the BIER adjacency details. We will check this point and include in
next revision. 
 
>if a BIER OAM packet experiences TTL expiry while in the middle of a

<Nagendra> Yes, Right. This needs to be clarified in the document. We will
include this in next revision.

>original TTL placed in the BIER-MPLS label by the initiator of the

<Nagendra> Thanks for the alternate suggestion. But I think it will suffer
the same problem. I will discuss this with other authors and update
accordingly.

>is useful to return in various troubleshooting scenarios.

<Nagendra> Sure. We will update with more details on the Return code.

Once again, thanks for the wonderful comments.

Regards,
Nagendra

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 13 Mar 2015 01:13:25 +0000

Uff, this is lots of enlightenment via email. Is it feasible we have something spun as 'inofficial' draft update before the IETF session and sent to this list so the interested parties read it up and we have a more solid base to discuss from ... 

> <Nagendra> LOL :). When I tried to locate the draft using ³bier + ping² in google,
> it pops a messages that an unusual search and asked me to confirm that I am
> human and not machine :)
> 
> > ...   

Yeah, the bier pong will be a classic, when Ice came out with the moniker we knew we're asking for all kind of puns of differing quality for the price of having an easily branded acronym with lots of positive associations within the demographics that IETF attracts ... 

--- tony

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Fri, 13 Mar 2015 12:39:25 +0000

Hi Tony,

Ok. I will try to get one shared with the group before the session.

Thanks,
Nagendra

On 3/12/15, 9:13 PM, "Antoni Przygienda" <[email-masked]>
wrote:

>Uff, this is lots of enlightenment via email. Is it feasible we have
>something spun as 'inofficial' draft update before the IETF session and
>sent to this list so the interested parties read it up and we have a more
>solid base to discuss from ...
>
>Yeah, the bier pong will be a classic, when Ice came out with the moniker
>we knew we're asking for all kind of puns of differing quality for the
>price of having an easily branded acronym with lots of positive
>associations within the demographics that IETF attracts ...
>
>--- tony
>

---

From: "Nobo Akiya" <[email-masked]>
Date: Sun, 22 Mar 2015 15:55:41 -0500

Hi Eric, Tony, Nagendra, et al,

Great comments and discussions!

I have further comments/questions. Please see in-line with [NOBO].

> From: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]]
> Sent: March-12-15 7:21 PM
> To: Eric C Rosen; Antoni Przygienda; [email-masked]
> Subject: Re: [Bier] I-D Action: draft-kumarzheng-bier-ping-00.txt
> 
> Hi Eric,
> 
google,
> it pops a messages that an unusual search and asked me to confirm that I
am

[NOBO] "bier-pong" is a great name! It's not too late to change :)

> 
> >
> >Any TLV that has a BitString and an SI also has to have a sub-domain
> >id, or else the set of BFERs identified in the BitString cannot be
anything
> in the reverse direction and can be IP based reply.

[NOBO] -00 proposes a field "Reply Mode" in the BIER OAM header which allows
an initiator of the operation to choose the reverse "channel" that responder
BFR uses.

                   Value      Meaning
                   --------  ---------------
                     1        Do not Reply
                     2        Reply via IPv4/IPv6 UDP packet.
                     3        Reply via BIER packet

This provides improved diagnostic capability (e.g., we can still diagnose
the BIER layer even if there's a temporary/persistent problem at the IP
layer), and I think this is a good thing. By "I'd think you'd want to avoid
BIER in the reverse direction ...", if there's a technical reason why we
should remove the "Reply via BIER packet" option, I'd like to hear the
reason.

> >respond.  (If you do use BIER for the responses, you'd certainly need
> >to know the sub-domain in which to interpret the BFIR, and you'd need
> >to know the sub-domain to choose the right BIER-MPLS label.)
> 
to
> fetch the BFR-Prefi form IGP database. But I think, it will be more clean
to have
> a TLV carrying the ³Reply-to² address which will more control to instruct
what
> address to reply to.
downstream
> neighbors to which the reply was sent, along with egress BitString that
will be
> sent to each downstream neighbor. IMHO, Initiator will be able to use
these
> information (along with sender handler) to portrait end to end path. How
it
> portrait the path would be a local matter, I think. We will include a
point in the
> procedure and mention it as local matter.
> 
needs to
> be clarified?.

[NOBO] The BIER OAM header has "Sequence Number" field which is set by the
initiator and incremented with every packet sent, and the responder BFRs
return this value the in reply. The initiator can use this "Sequence Number"
to correlate the ping to pong(s). How an initiator will do this is an
implementation matter, but I do think it's a good idea to capture the
Traceroute and TreeTrace flows in the document.

> generic. Do you think, it is reasonable to add an Appendix section to give
a
> couple of such examples from usage point of view?.

[NOBO] IMO, the critical aspect is that the implementation will need to take
the user specified <data stream> and generate the BIER header including the
Entropy field. The BIER OAM (i.e., Ping and Traceroute) is then ran on the
generated BIER header to troubleshot, which should traverse exactly the same
ECMP path as the <data stream> does.

> >stream, I think you'd need to know the entropy value of the data
> >packets in the troublesome data stream.  You'd want to specify the
> >entropy and find out what path is followed by packets to a given BFER
> >(or set of
> >would need to have an entropy value.  The draft doesn't seem to have
> >any provision for that.  (And unless deterministic ECMP is used, I'm
> >not sure this is a tractable problem at all.)
> 
the
> Initiator (assuming that is also acting as the ingress for the actual data
stream)
> to use the same Entropy value (that will be used in the data
BFRs. The
> other option is to query each BFR along the path about entropy range for
each
> ECMP path. This query does not need to carry any data stream details as
the
> entropy query is not specific to stream instead the path that will be
selected
> within a range. This is analogous to ECMP tree trace in MPLS LSP Ping.

[NOBO] IMO, I think the former is most usable. It means that the BIER OAM
CLI/API will allow users to specify the <data stream>, but I don't think the
BitString TLVs need to have any entropy values since the BIER header already
has the Entropy field (draft-wijnands-mpls-bier-encapsulation).

> >carried unchanged until there's a TTL expiry.  I think the request
> >needs to carry the original BIER header (augmented with SI and
> >sub-domain); this would be sent back in the response, along with the
> >corresponding information that is in the BIER header when the request
> >is received by the responder.  This would tell you which BFERs from the
> >original BitString are in the sub-tree of the responder.  (The document
> >does have a TLV for this.)
> 
> <Nagendra> Yes.
> >
> >possible ECMP paths that a packet might take, but I don't really see
> >how that is going to work in a scalable manner.
> 
per
> BFER. To troubleshoot a failure to a specific BFER or set of BFERs should
be
> possible by querying (and using) ECMP paths for one of the affected BFER
and
> use the entropy.
> 
> 
> >Also, I don't understand
> >the proposed use of the "Multipath Entropy TLV".  What value gets put
> >in it, and under what circumstances?
> 
not
> given). Will it be helpful to have an example in Appendix?.
> 
> >
deviation in
> HW/distributed forwarding. Per BFR-A control-plane, Bit-id 10 is reachable
via
> interface-A  while the data plane have a stale entry pointing towards
Interface-B.
> In this case, the reply from BFR-A will have downstream address which does
not
> match with upstream interface TLV of next response.

[NOBO] It is really the Downstream Mapping TLVs that provides the Traceroute
operation to perform the validation at every transit BFR. A BFR at TTL=n
will say outgoing adjacency is X in the Downstream Mapping TLV included in
the Reply. Initiator takes the Downstream Mapping TLV received from TTL=n in
the Reply and places the same Downstream Mapping TLV in the Request for
TTL=n+1. The BFR at TTL=n+1 will take the received Downstream Mapping TLV
and validates that the packet was indeed received on the "place" which is
described by the Downstream Mapping TLV.

Upstream Interface TLV is for every BFR to return the "place" which the BIER
packet was received from, so that initiator, thus user, has more information
of actual paths traversed in case of "problems".

> 
> 
> > If these are supposed to identify BIER adjacencies, then they need to
> >take account of the fact that a pair of adjacent BFRs might be
carry the
> BIER adjacency details. We will check this point and include in next
revision.

[NOBO] Does a pair of BFRs separated by an IP or MPLS tunnel still have a
direct BIER adjacencies at the BIER layer? If yes (and I think this is the
case, but do correct me if I'm wrong), then I think we are good as long as
we place clarifications in the OAM document.

> >traceroute procedures.  It's also worth thinking about what would
> >happen if a BIER OAM packet experiences TTL expiry while in the middle
> >of a unicast tunnel.
> 

[NOBO] Very good point. For the "uniform model", it might be safer so say
that the Tracerout operation cannot be supported, i.e., trying to tweak the
TTL at BFRs is error prone and can likely create more problems (e.g., tunnel
reopts, FRR, etc). Unless of course the BIER WG is ok placing a TTL/HopCount
in the BIER Header :)

> >It might make sense though for the sequence number to be the same as
> >the original TTL placed in the BIER-MPLS label by the initiator of the
> >request.
> 
the
> same problem. I will discuss this with other authors and update
accordingly.

[NOBO] Hmm... 

For Ping, number of responses == number of 1s in the BitString.

For Traceroute, TTL=n tells you how many downstreams there are. Thus number
of responses at TTL=n+1 == number of downstreams specified by TTL=n.

One thought triggered in my head as result is above comment, for TreeTrace,
is that the "downstreams" described by the BFR Reply need to differentiate
between replicated downstreams vs. ECMPed downstreams.

Thanks!

-Nobo

> 
> >
> >The return codes are not very well-defined, and it's not clear just
> >what the principles are that led to choosing that particular set of
> >return codes.  It would be good to see some discussion of what
> >information it is useful to return in various troubleshooting scenarios.
>