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

From: Mach Chen <[email-masked]>
Date: Wed, 3 Feb 2016 08:51:58 +0000

Hi Greg,

I'm surprised to see your reply at this time, what's your time zone? You are super!

I changed the email style to plaintext, please see my response inline...

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2016 4:21 PM
> To: Mach Chen; Carlos Pignataro (cpignata)
> Cc: [email-masked]
> Subject: RE: [Rtg-ooam-dt] BFD in BIER uploaded
> 
> 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,
> 
> 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.
> GIM>> I think that we can map SFC OAM domain to an SFC instance. Will iron
> precise wording.

In my memory, in the early version, an SFC instance is an SFC Path (SFP) that will include Classifier, SFFs and SFs. And I just had quick a lookup from RFC7665, seems there is no such a definition of SFC instance.
> 
> 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,
> GIM>> unambiguous, then SF, I think, may be presented as mapping
> GIM>> function between SFF and NFVi. Hence is may be put into Service
> GIM>> OAM layer with mapping in Overlay OAM. (Please let me know if I’m
> GIM>> miles off the chart with this.)

Reasonable to me. 

> 
> 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,

E2E is fine for me. But there are some special requirements to SFF, for example, an SFF has to differentiate a packet is OAM or normal data packet, for the OAM packet, specific to BFD control packet, it is required to forward it to next SFF other than to SF.  

I am also considering whether there is the hop-by-hop requirement, with hop-by-hop, it could perform some local protections (e.g., FRR) that may be desired to some critical services. . 

> 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.

It makes sense to me.

Best regards,
Mach 
> 
> 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,
> 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,
> 
> 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!
> 
> 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,
> 
> 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,
> 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]
> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 3 Feb 2016 09:05:17 +0000

Hi Mach,
that's simple :) this week I'm in Hong Kong @ BBF meeting.
My notes with GIM2>>.

	Best regards,
		Greg

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

Hi Greg,

> 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.
> GIM>> I think that we can map SFC OAM domain to an SFC instance. Will 
> GIM>> 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>> OAM layer with mapping in Overlay OAM. (Please let me know if 
> GIM>> I’m miles off the chart with this.)

Reasonable to me. 

> 
> 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?
> 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.

It makes sense to me.

Best regards,
Mach 
> 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
> 
> 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
> 
> 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)
> 
> service-hop-by-service-hop? Then we can talk about protocols, then 
> state machines and flows (e.g., discriminator adv), then encaps.
> 
> Thanks!
> 
> Carlos.
> 
> From: Rtg-ooam-dt [mailto:[email-masked]] On Behalf Of 
> Gregory Mirsky
> •         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: Wed, 3 Feb 2016 09:12:09 +0000

Now with notes :)

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

Hi Mach,

	Best regards,
		Greg

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

Hi Greg,

GIM2>> OK, let's change to SFP first and then we can communicate with SFC WG what SFP is.

Reasonable to me. 

E2E is fine for me. But there are some special requirements to SFF, for example, an SFF has to differentiate a packet is OAM or normal data packet, for the OAM packet, specific to BFD control packet, it is required to forward it to next SFF other than to SF.  
GIM2>> Don't we want layer encapsulation to include layer OAM as its payload? Then we define how ITP, and I think of SFF here still, processes OAM payload.

I am also considering whether there is the hop-by-hop requirement, with hop-by-hop, it could perform some local protections (e.g., FRR) that may be desired to some critical services. . 
GIM2>> I've been thinking that underlay network is reliable and overlay provides restoration, not protection. Let's discuss whether that seems right and what it means for OOAM Requirements.

It makes sense to me.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Wed, 3 Feb 2016 09:45:09 +0000

Hi Greg,

> Sent: Wednesday, February 03, 2016 5:12 PM
> In my memory, in the early version, an SFC instance is an SFC Path (SFP) that will
> include Classifier, SFFs and SFs. And I just had quick a lookup from RFC7665,
> seems there is no such a definition of SFC instance.
> 
> E2E is fine for me. But there are some special requirements to SFF, for example,
> an SFF has to differentiate a packet is OAM or normal data packet, for the OAM
> packet, specific to BFD control packet, it is required to forward it to next SFF
> other than to SF.
> GIM2>> Don't we want layer encapsulation to include layer OAM as its payload?
> Then we define how ITP, and I think of SFF here still, processes OAM payload.

It should, and for SFC, the ITP is required to process OAM payload in a different way from the data packet.

So, for e2e OAM, to generalize the Overlay OAM, there would be two options:

1 ) The intermediate node (e.g., ITP) will not give a special treatment to any packets (include data and OAM packets) unless ttl is expired or with some other exceptions, only the ETP will process the OAM packets.

2) The intermediate node will monitor every OAM packets and make a special process on the packet, just like a SFF in the SFC scenario.

> 
> I am also considering whether there is the hop-by-hop requirement, with
> hop-by-hop, it could perform some local protections (e.g., FRR) that may be
> desired to some critical services. .
> GIM2>> I've been thinking that underlay network is reliable and overlay
> provides restoration, not protection. Let's discuss whether that seems right
> and what it means for OOAM Requirements.

OK, let's hear other's opinions here.

> > <BFD for
> NSH.pptx>_______________________________________________
> > Rtg-ooam-dt mailing list
> > [email-masked]

---

From: Mach Chen <[email-masked]>
Date: Wed, 3 Feb 2016 09:46:26 +0000

Hi Greg,

Great, we will be in the same time zone this week, please enjoy your BBF meeting:-)

Best regards,
Mach

---

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

Hi,

Please see inline..

On 2/3/16, 4:45 AM, "Rtg-ooam-dt on behalf of Mach Chen"
<[email-masked] on behalf of [email-masked]> wrote:

>> I'm surprised to see your reply at this time, what's your time zone?
>>You are
>> super!
>> 
>> > thank you for the most insightful questions. I don¹t have answers to
>> > Indeed, the SFC OAM model does include SF. You introduced the ³SFC OAM
>> > domain², we need to firstly define this term.
>> GIM2>> OK, let's change to SFP first and then we can communicate with
>>SFC
>> WG what SFP is.
>> 
>> >
>> > GIM>> I¹m miles off the chart with this.)
>> 
>> Reasonable to me.
>> 
>> >
>> > hop-by-hop, what¹s thoughts about this?
>> > GIM>> We¹ve introduced Test Point (TP) object that includes behaviors
>1 ) The intermediate node (e.g., ITP) will not give a special treatment
>to any packets (include data and OAM packets) unless ttl is expired or
>with some other exceptions, only the ETP will process the OAM packets.
>
>2) The intermediate node will monitor every OAM packets and make a
>special process on the packet, just like a SFF in the SFC scenario.

<Nagendra> NSH draft instructs the SFF to look into the payload if O bit
is set. If I am following the thread right, ITP will be a transit SFF
(neither classifier nor last SFF). But with O bit set, it still look into
the payload.
>OK, let's hear other's opinions here.

<Nagendra> I think so. It will be good to have the E2E session validate
all ECMP underlay/overlay combination. But segmenting it to the respective
layer is still fine.

Thanks,
Nagendra

>> > and ping/traceroute localization.
>> 
>> It makes sense to me.
>> 
>> Best regards,
>> Mach
>> >
>> > Best regards,
>> > Mach
>> >
>> > 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.
>> > OOAM tool(s) that comply with the following requirement, i.e.
>>transcending
>> traceroute:
>> > Yes, I agree with you. That¹s the reason I listed the use case in the
>> > discuss it. I¹d encourage we start to discuss this by emails.
>> >
>> > Best regards,
>> > Mach
>> >
>> > 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
>_______________________________________________
>Rtg-ooam-dt mailing list
>[email-masked]