Subject: [Rtg-ooam-dt] BFD in BIER uploaded

From: Gregory Mirsky <[email-masked]>
Date: Mon, 1 Feb 2016 10:23:11 +0000

Dear All,
I may not be able to join in this week call (I'm on business trip UTC+8:00). Hence two requests:

*         please review and comment, send questions to BFD in BIER I've uploaded to OneDrive (attached just in case);

*         please try to have the meeting and share minutes.

Regards,
        Greg

---

From: Mach Chen <[email-masked]>
Date: Tue, 2 Feb 2016 09:59:11 +0000

Hi all,

Here are some thoughts about BFD for NSH, please review and comments

Best regards,
Mach

From: Rtg-ooam-dt [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Monday, February 01, 2016 6:23 PM
To: [email-masked]
Subject: [Rtg-ooam-dt] BFD in BIER uploaded

Dear All,

Regards,
        Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 2 Feb 2016 15:46:03 +0000

Thanks Mach!

I think the encapsulation is the easy part (BTW, missing RFC 5885-style in slide 3; also not totally clear what are the addresses in slides 3 and 4)

The more interesting problem and item to discuss is really more around use-cases, and around what problem are we solving. End-to-end? CC? service-hop-by-service-hop? Then we can talk about protocols, then state machines and flows (e.g., discriminator adv), then encaps.

Thanks!

Carlos.

> On Feb 2, 2016, at 4:59 AM, Mach Chen <[email-masked]> wrote:
> 
> Hi all,
> 
> From: Rtg-ooam-dt [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gregory Mirsky
> To: [email-masked] <mailto:[email-masked]>
> I may not be able to join in this week call (I’m on business trip UTC+8:00). Hence two requests:
> ·         please review and comment, send questions to BFD in BIER I’ve uploaded to OneDrive (attached just in case);
> ·         please try to have the meeting and share minutes.
> 
> Regards,
>         Greg
> <BFD for NSH.pptx>_______________________________________________
> Rtg-ooam-dt mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt <https://www.ietf.org/mailman/listinfo/rtg-ooam-dt>

---

From: Mach Chen <[email-masked]>
Date: Wed, 3 Feb 2016 03:33:24 +0000

Carlos,

Yes, I agree with you. That’s the reason I listed the use case in the slides and hoped we could discuss the during yesterday meeting. But unfortunately, the conference situation was bad and we failed to discuss it. I’d encourage we start to discuss this by emails.

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 02, 2016 11:46 PM
To: Mach Chen
Cc: Gregory Mirsky; [email-masked]
Subject: Re: [Rtg-ooam-dt] BFD in BIER uploaded

Thanks Mach!

Thanks!

Carlos.

On Feb 2, 2016, at 4:59 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Best regards,
Mach

From: Rtg-ooam-dt [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Monday, February 01, 2016 6:23 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Rtg-ooam-dt] BFD in BIER uploaded

Dear All,
I may not be able to join in this week call (I’m on business trip UTC+8:00). Hence two requests:
•         please review and comment, send questions to BFD in BIER I’ve uploaded to OneDrive (attached just in case);
•         please try to have the meeting and share minutes.

Regards,
        Greg
<BFD for NSH.pptx>_______________________________________________
Rtg-ooam-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtg-ooam-dt

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 3 Feb 2016 03:54:32 +0000

Hi Mach,
thank you for your contribution. Could you please upload it to the OneDrive?
My major question on SFC OAM is what you’ve reflected in slide 1:

·         is SFi part of SFC OAM domain or these belong to other layer OAM.
Current OAM model accepted by SFC WG does include SFi. I think that SFC OAM domain does not include SFi and traverses only SFFk. SFi to SFFk mapping is outside of OOAM scope and must be verifiable using OOAM tool(s) that comply with the following requirement, i.e. transcending traceroute:
[R14] Overlay OAM MAY support verification of the mapping between its data plane state and client layer services.

Greatly appreciate your questions, comments, point of view, arguments for or against either one of SFC OAM models.

                Regards,
                                Greg

From: Mach Chen [mailto:[email-masked]]
Sent: Wednesday, February 03, 2016 11:33 AM
To: Carlos Pignataro (cpignata)
Cc: Gregory Mirsky; [email-masked]
Subject: RE: [Rtg-ooam-dt] BFD in BIER uploaded

Carlos,

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 02, 2016 11:46 PM
To: Mach Chen
Cc: Gregory Mirsky; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rtg-ooam-dt] BFD in BIER uploaded

Thanks Mach!

Thanks!

Carlos.

Hi all,

Best regards,
Mach

Dear All,

Regards,
        Greg

---

From: Mach Chen <[email-masked]>
Date: Wed, 3 Feb 2016 07:21:39 +0000

Hi Greg and all,

Sure, will upload it to the OneDrive later.

Indeed, the SFC OAM model does include SF. You introduced the “SFC OAM domain”, we need to firstly define this term.

I am fine with the scope that the SFC BFD, Ping and traceroute just cover SFFs and the paths among them, and if so, the solution would be simpler than the case where the SFs are also included. But we should give some reasons/considerations why SFs are excluded.

In addition, if the SFC BFD only covers SFFs, there are also some differences from the existing BFD applications. A SFF will determine whether a BFD control packet should be terminated or forwarded to the next SFF. This depends on whether the BFD session is end-2-end or hop-by-hop, what’s thoughts about this?

Best regards,
Mach

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, February 03, 2016 11:55 AM
To: Mach Chen; Carlos Pignataro (cpignata)
Cc: [email-masked]
Subject: RE: [Rtg-ooam-dt] BFD in BIER uploaded

Hi Mach,

                Regards,
                                Greg

Carlos,

Best regards,
Mach

Thanks Mach!

Thanks!

Carlos.

Hi all,

Best regards,
Mach

Dear All,

Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 3 Feb 2016 08:20:55 +0000

Hi Mach,
thank you for the most insightful questions. I don’t have answers to all but let us work through and will certainly get them together.
Please find my notes in-line and tagged GIM>>.

                Best regards,
                                Greg

From: Mach Chen [mailto:[email-masked]]
Sent: Wednesday, February 03, 2016 3:22 PM
To: Gregory Mirsky; Carlos Pignataro (cpignata)
Cc: [email-masked]
Subject: RE: [Rtg-ooam-dt] BFD in BIER uploaded

Hi Greg and all,

Indeed, the SFC OAM model does include SF. You introduced the “SFC OAM domain”, we need to firstly define this term.
GIM>> I think that we can map SFC OAM domain to an SFC instance. Will iron precise wording.

I am fine with the scope that the SFC BFD, Ping and traceroute just cover SFFs and the paths among them, and if so, the solution would be simpler than the case where the SFs are also included. But we should give some reasons/considerations why SFs are excluded.
GIM>> If mapping between SF and NFV instance (NFVi) is deterministic, unambiguous, then SF, I think, may be presented as mapping function between SFF and NFVi. Hence is may be put into Service OAM layer with mapping in Overlay OAM. (Please let me know if I’m miles off the chart with this.)

In addition, if the SFC BFD only covers SFFs, there are also some differences from the existing BFD applications. A SFF will determine whether a BFD control packet should be terminated or forwarded to the next SFF. This depends on whether the BFD session is end-2-end or hop-by-hop, what’s thoughts about this?
GIM>> We’ve introduced Test Point (TP) object that includes behaviors analogous to both MEP and MIP. We can refer to these as End TP (ETP) and Intermediate TP (ITP) respectively. Then BFD session is between ETPs, i.e. e2e, while ping and traceroute expose ITPs, i.e. SFF. Does that make sense? I think that may be sufficient as BFD would enable defect detection and ping/traceroute –localization.

Best regards,
Mach

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

Hi Mach,

                Regards,
                                Greg

Carlos,

Best regards,
Mach

Thanks Mach!

Thanks!

Carlos.

Hi all,

Best regards,
Mach

Dear All,

Regards,
        Greg

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 3 Feb 2016 13:53:48 +0000

Hi Greg,

Per SFC OAM framework draft, the validating the SF functionality/policy is out of scope. But I think SF availability check should be considered. We also have below requirement for OOAM:

[R6] Overlay OAM packets MUST be in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, and i.e. from ingress toward egress end-point of the OAM test session.

Terminating only on the SFF or skipping the SF for E2E SFC validation may violate the above requirement. Like Carlos said, I think a scope on use cases to be considered will help us narrow down further (or refine our requirements).

Thanks,
Nagendra

From: Rtg-ooam-dt <[email-masked]<mailto:[email-masked]>> on behalf of Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 2, 2016 at 10:54 PM
To: Mach Chen <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rtg-ooam-dt] BFD in BIER uploaded

Hi Mach,
thank you for your contribution. Could you please upload it to the OneDrive?
My major question on SFC OAM is what you've reflected in slide 1:

                Regards,
                                Greg

Carlos,

Yes, I agree with you. That's the reason I listed the use case in the slides and hoped we could discuss the during yesterday meeting. But unfortunately, the conference situation was bad and we failed to discuss it. I'd encourage we start to discuss this by emails.

Best regards,
Mach

Thanks Mach!

Thanks!

Carlos.

Hi all,

Best regards,
Mach

Dear All,
I may not be able to join in this week call (I'm on business trip UTC+8:00). Hence two requests:
·         please review and comment, send questions to BFD in BIER I've uploaded to OneDrive (attached just in case);
·         please try to have the meeting and share minutes.

Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 9 Feb 2016 00:17:56 +0000

Hi Mach and All,
happy New Year to All! May it be healthy, happy and fulfill our dreams.

Yes, perhaps we should use SFP OAM rather than SFC OAM. What do you think?
In the Gap Analysis we should consider two models for SFP OAM:

·         one that includes SF;

·         one that doesn’t include SF.
In case of the former, I think, there’s clear requirement towards an SF to support SFP OAM functionality. In the latter case SF would be out the scope of SFP OAM and, as we’ve discussed, SFF-SF mapping may be verified. [Q] Do we extend it to be discovered (I’m concerned with security of anything discoverable)?
For BFD in ACH format I’d prefer use of bootstrapping rather than Source ID TLV in each and every CC packet. But Source ID TLV must be used if we to provide proactive CV (Connectivity Verification) re-using BFD.

Comments, suggestions and updates to our documents on OneDrive greatly appreciated, encouraged.

                Regards,
                                Greg

From: Mach Chen [mailto:[email-masked]]
Sent: Tuesday, February 02, 2016 11:22 PM
To: Gregory Mirsky; Carlos Pignataro (cpignata)
Cc: [email-masked]
Subject: RE: [Rtg-ooam-dt] BFD in BIER uploaded

Hi Greg and all,

Best regards,
Mach

Hi Mach,

                Regards,
                                Greg

Carlos,

Best regards,
Mach

Thanks Mach!

Thanks!

Carlos.

Hi all,

Best regards,
Mach

Dear All,

Regards,
        Greg