Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

From: "Susan Hares" <[email-masked]>
Date: Thu, 10 Mar 2022 09:38:43 -0500

Greeting: 

This begins a 2 week WG Adoption call (3/10/2022 to 3/24/2022) 

for draft-wang-idr-bgp-ifit-capabilities-04

https://datatracker.ietf.org/doc/draft-wang-idr-bgp-ifit-capabilities/

In your comments please consider if: 

1) Do the additions to BGP (2 Communities and 

TLV for next-hop-capability attribute) 

help the distribute information regarding the  IFIT options 

from tail (egress) nodes to head nodes (ingress)?  

Are there any cases where these BGP 

Communities should be removed or ignored?  

2) Are the mechanisms (2 Communities and 

attribute TLV) correctly specified? 

3) How do these additions interaction with the 

  With SR technology for IFIT described in 

   draft-ietf-idr-sr-policy-ifit, and its 

   use of RFC9012 (tunnel attributes)? 

(Authors an example on how these

technologies work together or 

 operate separately would be helpful). 

4)  Will this addition help network operators 

deploying IFIT technology? 

Cheerily, Sue

---

From: Haoyu Song <[email-masked]>
Date: Fri, 11 Mar 2022 17:50:19 +0000

Hi IDR WG,

I support the adoption of this draft. The proposed BGP extension is reasonable and useful to advertise the telemetry capabilities.

Best regards,
Haoyu

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 6:39 AM
To: [email-masked]
Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Greeting:

Cheerily, Sue

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 11 Mar 2022 13:17:12 -0500

Sue and Working Group,

I'm generally supportive of IFIT for BGP.  

For this particular document, I think it'd be helpful if the authors 
provided some more detail on the scoping of the BGP Extended Community 
attributes and their security considerations.

In particular:

>From the Security Considerations for draft-ietf-idr-sr-policy-ifit-03:

:   IFIT data MUST be propagated in a limited domain in order to avoid
:   malicious attacks and solutions to ensure this requirement are
:   respectively discussed in [I-D.ietf-ippm-ioam-data] and
:   [I-D.ietf-6man-ipv6-alt-mark].

The NextHop Capability leveraged in this draft as part of prior learnings
has specified itself as an Optional, Non-Transitive Path Attribute.  This
means that behaviors can be enforced on a hop-by-hop basis.

BGP Extended Communities are only scoped for as-transitive or not.

It'd be useful for the authors to comment on what the expected behaviors for
BGP speakers downstream of not the IFIT egress. Also, potentially outside
of the IFIT domain.  What are the Security Considerations for such
additional propagation of these Extended Communities?

I'm unclear whether the intent of the Extended Communities is whether they
should ONLY be propagated with the NextHop Capability or not.

Please note that forms of this question were raised both on the mailing list
in prior threads and also during IDR IETF sessions.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Mar 2022 21:33:29 +0100

Hello Jeff & WG,

I am a big supporter of In-Situ Telemetry. Well modulo the fact - and in
fact show stopper - that to make it really useful very precise nano seconds
clock synchronization is required and that by itself is not an easy task to
accomplish in WAN or MAN networks. The only tools I see to help here are
PTP or gPTP but PTP mostly is deployable in DCs not in WANs.

As far as BGP is concerned I must ask why do we really need p2mp signalling
to spray such information to all BGP speakers ? In Situ telemetry can be
deployed end to end beyond BGP speaking network elements so it will not
help.

Moreover we are really stepping again on using BGP protocol as a network
management carrier. Such distribution would be much better served by the
pub-sub model. Such model can be realized by any message bus or by
leveraging a recent proposal from Tony -
https://datatracker.ietf.org/doc/draft-li-lsr-liveness/  Yes this currently
was done to address IGP node liveness propagation, but nothing stands
against reusing such idea for pub-sub distribution of other node
capabilities like ifit.

Bottom line - not everything that can be fitted into a BGP attribute should
be carried by BGP protocol.

Kind regards,
R.

On Fri, Mar 11, 2022 at 7:17 PM Jeffrey Haas <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 16 Mar 2022 11:01:02 +0000

Dear Sue, All,
I support the adoption of draft-wang-idr-bgp-ifit-capabilities. It provides a solution for IFIT capability advertisement in order to communicate the supported and unsupported IFIT methods though BGP. It will therefore help with the IFIT deployment.
Regarding the relation with draft-ietf-idr-sr-policy-ifit, I think that the two drafts can be considered independent. Indeed draft-wang-idr-bgp-ifit-capabilities aims to define a general approach for IFIT capability advertisement for IPv4/IPv6 networks. While draft-ietf-idr-sr-policy-ifit applies specifically to SR Policy and, as an extension of draft-ietf-idr-segment-routing-te-policy, it allows to distribute SR policies carrying IFIT information and provides the configurable knobs of the supported IFIT methods at candidate path level.

Regards,

Giuseppe

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 3:39 PM
To: [email-masked]
Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Greeting:

Cheerily, Sue

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 17 Mar 2022 07:40:07 +0000

Dear Sue, WG,

I support the adoption of draft-wang-idr-bgp-ifit-capabilities.

1)  Yes it will help.  At present, IFIT has been deployed, and the tail node relies on manual configuration to determine which IFIT capabilities to handle, which is tedious and error-prone. Draft-wang-idr-bgp-ifit-capabilities will facilitate the deployment of IFIT measurements on a per-service and on-demand basis dynamically.
The announcement of the BGP communities are controlled per-peer and hop-by-hop. When the tail node receives it, it will not be further announce.

2) Yes. We co-authors believe that suitable solutions are currently designed and hope to improve these solutions with the joint efforts of the working group.

3) Regarding the relation with draft-ietf-idr-sr-policy-ifit, I think that the two drafts can be considered independent and complementary, they are applied in different scenarios.
Draft-wang-idr-bgp-ifit-capabilities can be considered as a general distributed solution that does not require the participation of centralized control element, while draft-ietf-idr-sr-policy-ifit allows to distribute SR policies from a centralized control element and it can be considered as a centralized control solution.

4) Yes. We co-authors believe that it will help network operators deploying the IFIT technology.  We would also like to receive more comments from network operators, and improve the solution described in this draft.

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:39 PM
To: [email-masked]
Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Greeting:

Cheerily, Sue

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Thu, 17 Mar 2022 11:53:01 +0000

Hi Robert,

       [Bottom line - not everything that can be fitted into a BGP attribute should be carried by BGP protocol.]
    I agree with this point.

    But I still think the iFit extension here is appropriate.
  The Pub-sub model is a centralized service model, it’s complexable for dynamic changed service.
    The iFit extension here is a distributed service driven model. Service routes advertised with iFit capability will bring simplifying deployment.

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Saturday, March 12, 2022 4:33 AM
To: Jeffrey Haas <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hello Jeff & WG,

I am a big supporter of In-Situ Telemetry. Well modulo the fact - and in fact show stopper - that to make it really useful very precise nano seconds clock synchronization is required and that by itself is not an easy task to accomplish in WAN or MAN networks. The only tools I see to help here are PTP or gPTP but PTP mostly is deployable in DCs not in WANs.

As far as BGP is concerned I must ask why do we really need p2mp signalling to spray such information to all BGP speakers ? In Situ telemetry can be deployed end to end beyond BGP speaking network elements so it will not help.

Moreover we are really stepping again on using BGP protocol as a network management carrier. Such distribution would be much better served by the pub-sub model. Such model can be realized by any message bus or by leveraging a recent proposal from Tony - https://datatracker.ietf.org/doc/draft-li-lsr-liveness/  Yes this currently was done to address IGP node liveness propagation, but nothing stands against reusing such idea for pub-sub distribution of other node capabilities like ifit.

Bottom line - not everything that can be fitted into a BGP attribute should be carried by BGP protocol.

Kind regards,
R.

On Fri, Mar 11, 2022 at 7:17 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Sue and Working Group,

In particular:

-- Jeff

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Mar 2022 13:37:43 +0100

Haibo,

Sure I get your objective here.

The point is that sending anything in dynamic routing protocol is sound
only when receivers perform well defined actions on the received data.

Here you however still need a process (likely management driven) to trigger
telemetry sessions as any to any for all negotiated capabilities hardly
makes sense. Leave alone clock sync point I mentioned before what BGP (I
hope) will not be asked to signal.

So this proposal creates a local database with remote telemetry peers and
their capabilities on each BGP speaker. What if I want to use In-situ Flow
Information Telemetry between my 10 sites over Internet ? That means that
millions of other Internet routers will now have to carry this extended
community (or extension to NH Capability Attribute) ?

How would it even work for my use case if lot's of ISPs filters extended
communities and NH Capability Attribute is non-transitive by design ?

I am still not convinced this is good idea to add this as general extension
to BGP.

Many thx,
R.

On Thu, Mar 17, 2022 at 12:53 PM Wanghaibo (Rainsword) <
[email-masked]> wrote:

> Hi Robert,
>
>
>
>        [Bottom line - not everything that can be fitted into a BGP
> attribute should be carried by BGP protocol.]
>
>     I agree with this point.
>
>
>
>     The iFit extension here is a distributed service driven model. Service
> routes advertised with iFit capability will bring simplifying deployment.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, March 12, 2022 4:33 AM
> *To:* Jeffrey Haas <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>; Susan Hares <[email-masked]>
> *Subject:* Re: [Idr] Adoption call for
> draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)
>
>
>
> Hello Jeff & WG,
>
>
>
> As far as BGP is concerned I must ask why do we really need p2mp
> signalling to spray such information to all BGP speakers ? In Situ
> telemetry can be deployed end to end beyond BGP speaking network elements
> so it will not help.
>
>
>
> https://datatracker.ietf.org/doc/draft-li-lsr-liveness/  Yes this
> currently was done to address IGP node liveness propagation, but nothing
> stands against reusing such idea for pub-sub distribution of other node
> capabilities like ifit.
>
>
>

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 17 Mar 2022 12:46:02 +0000

Dear Jeff,

Thanks for your useful comments!
Please see the reply with [SW].

Best regards,
Shunwan

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Saturday, March 12, 2022 2:17 AM
> To: Susan Hares <[email-masked]>
> Cc: [email-masked]
[SW] Thanks for your support!

> For this particular document, I think it'd be helpful if the authors provided
> some more detail on the scoping of the BGP Extended Community attributes
> and their security considerations.
> 
> In particular:
> 
> > 1) Do the additions to BGP (2 Communities and TLV for
> > next-hop-capability attribute) help the distribute information
> > regarding the  IFIT options from tail (egress) nodes to head nodes
> > (ingress)?
> >
> The NextHop Capability leveraged in this draft as part of prior learnings has
> specified itself as an Optional, Non-Transitive Path Attribute.  This means
> that behaviors can be enforced on a hop-by-hop basis.

[SW] Yes, your interpretation is correct. We will add more explicit descriptions in next version.
> BGP Extended Communities are only scoped for as-transitive or not.

[SW] They should be non-transitive. We will update in next version.
 
> 
> It'd be useful for the authors to comment on what the expected behaviors
> for BGP speakers downstream of not the IFIT egress. Also, potentially outside

[SW] Only the IFIT egress will advertise IFIT capabilities to the IFIT Ingress. The IFIT egress will have explicit enable knob, and the announcement of the extended community attributes is also explicitly controlled on a peer-by-peer basis.

> should ONLY be propagated with the NextHop Capability or not.

[SW] Hopefully the working group can help make that choice. 
When we designed the solution, considering that the implementation of the NextHop Capability attribute with the Entropy label capability, we feel that the NextHop Capability solution maybe the future direction. While the BGP extended community attribute solution is the simplest and easy to deploy. Therefore, we provide 2 options in the draft.

Thanks again,
Shunwan
> 
> Please note that forms of this question were raised both on the mailing list in
> prior threads and also during IDR IETF sessions.
> 
> -- Jeff
>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Mar 2022 09:22:58 +0800

Hi, all

    I support the adoption. It is necessary for the deployment of IFIT in the network.

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Susan Hares
Date: 2022-03-10 22:38
To: [email-masked]

 

 

Cheerily, Sue

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 18 Mar 2022 01:52:35 +0000

Hi Robert，

This solution depends on the application scenario.
Generally, this configuration is not applicable to common Internet services. This solution is deployed in a limited domain.

Regards,
Haibo

From: Robert Raszuk [mailto:[email-masked]]
Sent: Thursday, March 17, 2022 8:38 PM
To: Wanghaibo (Rainsword) <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>; idr@ietf. org <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Haibo,

The point is that sending anything in dynamic routing protocol is sound only when receivers perform well defined actions on the received data.

Here you however still need a process (likely management driven) to trigger telemetry sessions as any to any for all negotiated capabilities hardly makes sense. Leave alone clock sync point I mentioned before what BGP (I hope) will not be asked to signal.

So this proposal creates a local database with remote telemetry peers and their capabilities on each BGP speaker. What if I want to use In-situ Flow Information Telemetry between my 10 sites over Internet ? That means that millions of other Internet routers will now have to carry this extended community (or extension to NH Capability Attribute) ?

How would it even work for my use case if lot's of ISPs filters extended communities and NH Capability Attribute is non-transitive by design ?

I am still not convinced this is good idea to add this as general extension to BGP.

Many thx,
R.

On Thu, Mar 17, 2022 at 12:53 PM Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Regards,
Haibo

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Saturday, March 12, 2022 4:33 AM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hello Jeff & WG,

Kind regards,
R.

In particular:

-- Jeff

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Mar 2022 11:43:14 +0800

Hi All,
 
I have read this draft, this draft defines extensions to BGP to advertise the IFIT capabilities of the egress node to the ingress node in an IFIT domain.
This draft does not conflict with draft-ietf-idr-sr-policy-ifit and is very useful in the networks where no controller is introduced, it help network operators to deploy IFIT in their networks.
I support the WG adoption of this draft.
 
Cheerily,
Yongqing 

[email-masked]

Greeting: 

 

 

Cheerily, Sue

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Mar 2022 01:02:58 -0400

Hi Sue & WG

I Support WG adoption.

I believe this draft will help operators in distribution of IFIT telemetry
 capabilities from tail to head end nodes.  The draft needs to describe
more clearly what the new extended communities are to be used for.  Is is
not clear the use.

The draft iFIT SR policy draft below is completely independent of this
draft and is used to distribute SR policy containing IFIT information.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-ifit-03

I think this draft will help in the deployment of IFIT technology.

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gert Doering <[email-masked]>
Date: Fri, 18 Mar 2022 09:29:26 +0100

Hi,

> Generally, this configuration is not applicable to common Internet services. This solution is deployed in a limited domain.

Maybe then it should not be in a protocol built for common Internet services.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Mar 2022 09:56:52 +0100

Spot on Gert !

In a "limited domain" - whatever that means (and yes I have seen a draft
trying to explain that buzzword) - you have a common management plane which
can automatically orchestrate the network.

We can't load more "stuff" on a routing protocol especially where it is
already clear that it will not work for all legitimate use cases.

Moreover separating such stuff (aside from evaluating how useful it is)
into a separate address family where "limited domain" can enable and run
could perhaps could be ok. But adding such things to Internet unicast IPv4
and IPv6 SAFI is a very dangerous precedent with potential global impact
day one when anyone enables it.

Non transitive NH Capability Attribute perhaps is ok, but transitive
community for a local "limited domain" stuff is IMHO not acceptable. But as
stated before this type of information does not fit the spray and pray
distribution model.

I wonder what must happen before folks wake up and seriously consider
adding pub-sub mechanism to IP networks to distribute such and similar
information and offload routing protocols from doing it just for
convenience of already being there.

Thx,
Robert.

On Fri, Mar 18, 2022 at 9:29 AM Gert Doering <[email-masked]> wrote:

> > Generally, this configuration is not applicable to common Internet
> services. This solution is deployed in a limited domain.
>

---

From: Zhuangshunwan <[email-masked]>
Date: Sat, 19 Mar 2022 01:23:59 +0000

Hi Gyan,

Thanks for your support!
Regarding the new extended communities, we will add some clearer description based on comments and input from the working group.

Best Regards,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Friday, March 18, 2022 1:03 PM
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Sue & WG

I Support WG adoption.

I believe this draft will help operators in distribution of IFIT telemetry  capabilities from tail to head end nodes.  The draft needs to describe more clearly what the new extended communities are to be used for.  Is is not clear the use.

The draft iFIT SR policy draft below is completely independent of this draft and is used to distribute SR policy containing IFIT information.

Kind Regards

Gyan

On Thu, Mar 10, 2022 at 9:39 AM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Greeting:

Cheerily, Sue

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 21 Mar 2022 14:21:37 +0800

Hi, Sue:

Support its adoption.

I think the per-service iFIT capabilities advertisement is necessary,
especially for the BGP related services that span the different ASes, but in
the one limited domain.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:39 PM
To: [email-masked]
Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04
(3/10 to 3/24)

Greeting: 

 

 

Cheerily, Sue

---

From: Lizhenbin <[email-masked]>
Date: Mon, 21 Mar 2022 12:52:21 +0000

Hi All,

This draft defines extensions to BGP to advertise the IFIT capabilities of the egress node to the ingress node in an IFIT domain.
The solutions defined in this draft will help operators deploy iFIT technology in the networks where no controller is introduced.
That is, it is used in distributed scenarios and does not require the participation of the centralized network element. So it is a totally
different solution from draft-ietf-idr-sr-policy-ifit.

Best Regards,
Zhenbin (Robin)

Greeting:

Cheerily, Sue

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 23 Mar 2022 02:22:18 +0000

Hi Chairs and WG,

I support the adoption of this draft.
In my opinion, this is an easy extension to BGP.
It helps the ingress node to know if the egress node can process on path telemetry, and prevent potential forwarding fail.

Cheers,
Tianran

Greeting:

Cheerily, Sue

---

From: "Yangfan(Fan,IP Standards)" <[email-masked]>
Date: Wed, 23 Mar 2022 06:43:57 +0000

Hi IDR,

I support the WG adoption of this draft.
Replies to chair's questions:

1)       Yes, the extensions  do help the IFIT capability  advertisement from tail to head.

The capability should be refreshed when BGP peers are reestablished.

2)       Yes, the extensions are correctly specified.

3)       It surely helps if authors can add texts on how different extensions are used in each case, but IMHO not much necessary.

4)       Yes, it does help.

Best regards,
Fan

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:39 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Greeting:

Cheerily, Sue

---

From: 庞冉(联通集团中国联通研究院-本部) <[email-masked]>
Date: Wed, 23 Mar 2022 12:52:49 +0000

Hi all,

I support the adoption. This draft will help operators deploy iFIT technology.

Best regards,
Pang Ran.

From: Susan Hares<mailto:[email-masked]>
Date: 2022-03-10 22:38
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)
Greeting:

Cheerily, Sue
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 23 Mar 2022 20:10:36 +0530

Hi Sue,

Summary: I don't believe the draft is ready for WG adoption as yet.

Disclaimer: I do not fully understand the IFIT framework to judge if
carrying/signaling this information in BGP makes sense. I'll leave that to
others that do understand IFIT.

That said, I don't see the introduction discussing why this is appropriate
in BGP. Since it talks about limited domain and overlay service, I am not
able to follow how it helps signal only the capabilities of the PEs in a
BGP-free core. Are capabilities not required for all nodes?

Coming to the draft itself and the BGP mechanics, there are some issues in
the draft.

First, which SAFI routes are these extensions going to get signaled with?
Please point me to the text if I am missing something.

Second, the draft describes two options. I have not seen any discussion
either in the draft or on the IDR list on which of the two (or both?) are
suitable. The only one to touch on this topic has been Jeff and the
response to him was for the WG to pick. I think the WG needs to see those
updates and the analysis in the document to be able to make that decision.

Alternately, can the proponents pick one? And if both are needed, clarify
why?

The current draft says that the new community is transitive, but I guess it
was meant to be non-transitive based on Shunwan's response? Would be
important to fix that.

Please see inline responses to your specific questions.

KT> I don't know since the draft does not specify how this works.

KT> Yes, but a bigger concern is that they are defined as transitive.

KT> A concern is why two?

KT> I did not see any reference to RFC9012

KT> Unable to determine.

Thanks,
Ketan

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 24 Mar 2022 15:23:38 +0530

A correction - Robert has also brought out some of the same points and I
missed that when I said in my email that only Jeff covered them.

This correction is important for the authors since Robert has touched upon
the implications (I have not).

Thanks,
Ketan

On Wed, Mar 23, 2022 at 8:10 PM Ketan Talaulikar <[email-masked]>
wrote:

> The current draft says that the new community is transitive, but I guess
> it was meant to be non-transitive based on Shunwan's response? Would be
> important to fix that.
>

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 24 Mar 2022 13:46:21 +0000

Hi Ketan,

“That said, I don't see the introduction discussing why this is appropriate in BGP. Since it talks about limited domain and overlay service, I am not able to follow how it helps signal only the capabilities of the PEs in a BGP-free core. Are capabilities not required for all nodes?”

[ZTR] In the IFIT detection domain, Ingress node inserts IFIT detection header into each selected flow packet, and the egress node remove the IFIT detection header from the packet, make sure IFIT detection header only happened in the IFIT detection domain.
       IFIT detection currently mainstream solution include E2E and hop-by-hop detection.
in E2E detection scenario, only ingress and egress node do the detection, transit node only transparent service flow with IFIT detection header
in hbh detection scenario, all the nodes along the service path can do the detection, and if one transit node does not support IFIT detection, does not impact other nodes working on detection.
However, only PE nodes(include ingress and egress node) need insert or remove IFIT detection header.
So that, ingress node do the IFIT header insert operation only it makes sure egress node can remove IFIT header, otherwise, egress node will drop the flow packet embedded IFIT detection header due to it does not recognize this packet.
One available solution is that egress node notify ingress node before IFIT start detection, such as through method mentioned in the draft.

“First, which SAFI routes are these extensions going to get signaled with? Please point me to the text if I am missing something.”

[ZTR] This idea mainly suit for VPN scenarios, such as EVPNv4,EVPNv6,L2EVPN(EVPN VPWS and EVPN VPLS) routes... if needed can add the description in the update version.

Many thanks,
Tianran

From: Idr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar
Sent: Wednesday, March 23, 2022 10:41 PM
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Sue,

Disclaimer: I do not fully understand the IFIT framework to judge if carrying/signaling this information in BGP makes sense. I'll leave that to others that do understand IFIT.

That said, I don't see the introduction discussing why this is appropriate in BGP. Since it talks about limited domain and overlay service, I am not able to follow how it helps signal only the capabilities of the PEs in a BGP-free core. Are capabilities not required for all nodes?

Coming to the draft itself and the BGP mechanics, there are some issues in the draft.

First, which SAFI routes are these extensions going to get signaled with? Please point me to the text if I am missing something.

Second, the draft describes two options. I have not seen any discussion either in the draft or on the IDR list on which of the two (or both?) are suitable. The only one to touch on this topic has been Jeff and the response to him was for the WG to pick. I think the WG needs to see those updates and the analysis in the document to be able to make that decision.

Alternately, can the proponents pick one? And if both are needed, clarify why?

The current draft says that the new community is transitive, but I guess it was meant to be non-transitive based on Shunwan's response? Would be important to fix that.

KT> Unable to determine.

Thanks,
Ketan

On Thu, Mar 10, 2022 at 8:09 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Greeting:

Cheerily, Sue

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 24 Mar 2022 20:17:28 +0530

Hi Tianran,

Please check inline below.

On Thu, Mar 24, 2022 at 7:16 PM Tianran Zhou <[email-masked]> wrote:

> Hi Ketan,
>
>
>
> “That said, I don't see the introduction discussing why this is
> appropriate in BGP. Since it talks about limited domain and overlay
> service, I am not able to follow how it helps signal only the capabilities
> of the PEs in a BGP-free core. Are capabilities not required for all nodes?”
>
>
>
> [ZTR] In the IFIT detection domain, Ingress node inserts IFIT detection
> header into each selected flow packet, and the egress node remove the IFIT
> detection header from the packet, make sure IFIT detection header only
> happened in the IFIT detection domain.
>
> in E2E detection scenario, only ingress and egress node do the detection,
> transit node only transparent service flow with IFIT detection header
>
> in hbh detection scenario, all the nodes along the service path can do the
> detection, and if one transit node does not support IFIT detection, does
> not impact other nodes working on detection.
>
> So that, ingress node do the IFIT header insert operation only it makes
> sure egress node can remove IFIT header, otherwise, egress node will drop
> the flow packet embedded IFIT detection header due to it does not recognize
> this packet.
>
> One available solution is that egress node notify ingress node before IFIT
> start detection, such as through method mentioned in the draft.
>

KT> It would be good if some of this context is described in the draft. A
follow-on, if we have a mechanism for signaling IFIT capabilities
hop-by-hop then does that not also cover end to end?

>
>
>
>
> “First, which SAFI routes are these extensions going to get signaled with?
> Please point me to the text if I am missing something.”
>
>
>
> [ZTR] This idea mainly suit for VPN scenarios, such as
> EVPNv4,EVPNv6,L2EVPN(EVPN VPWS and EVPN VPLS) routes... if needed can add
> the description in the update version.
>

KT> This is now very confusing to me. I thought this was something between
PEs - what you refer to as IFIT encapsulating node. I no more understand
why this needs to be associated with a service route?

Thanks,
Ketan

>
>
> Many thanks,
>
> Tianran
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Ketan Talaulikar
> *Sent:* Wednesday, March 23, 2022 10:41 PM
> *To:* Susan Hares <[email-masked]>
> *Cc:* [email-masked]

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 25 Mar 2022 02:39:12 +0000

Hi Ketan,

Please check inline below with [SW].

Kind Regards,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar
Sent: Thursday, March 24, 2022 10:47 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Tianran,

On Thu, Mar 24, 2022 at 7:16 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

KT> It would be good if some of this context is described in the draft. A follow-on, if we have a mechanism for signaling IFIT capabilities hop-by-hop then does that not also cover end to end?

[SW] Surely, the above context will be added in the future version. We also especially welcome your help in improving this work.
Yes, the hop-by-hop mechanism will be a long-term solution we pursue,  In the current stage where new and old devices are deployed together, we must first ensure that the tailend node can properly decapsulate the IFIT shim header. Therefore, a solution for signaling the IFIT capability between the headend and tailend nodes is also necessary.

KT> This is now very confusing to me. I thought this was something between PEs - what you refer to as IFIT encapsulating node. I no more understand why this needs to be associated with a service route?

[SW]  This is actually a commonly used approach, such as the EVPN route carrying the Encapsulation Extended Community. Using this approach, service-driven deployment of IFIT can be achieved.

Thanks,
Ketan

Many thanks,
Tianran

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ketan Talaulikar
Sent: Wednesday, March 23, 2022 10:41 PM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Sue,

KT> Unable to determine.

Thanks,
Ketan

Cheerily, Sue

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 25 Mar 2022 09:25:36 +0530

Hi Shunwan,

Please check inline below with KT2.

On Fri, Mar 25, 2022 at 8:09 AM Zhuangshunwan <[email-masked]>
wrote:

> *Sent:* Thursday, March 24, 2022 10:47 PM
> *To:* Tianran Zhou <[email-masked]>
> *Cc:* [email-masked]; Susan Hares <[email-masked]>
> [SW] Surely, the above context will be added in the future version. We
> also especially welcome your help in improving this work.
>
> Yes, the hop-by-hop mechanism will be a long-term solution we pursue,  In
> the current stage where new and old devices are deployed together, we must
> first ensure that the tailend node can properly decapsulate the IFIT shim
> header. Therefore, a solution for signaling the IFIT capability between the
> headend and tailend nodes is also necessary.
>

 KT2> Fair enough. Look forward to the updates.

> [SW]  This is actually a commonly used approach, such as the EVPN route
> carrying the Encapsulation Extended Community. Using this approach,
> service-driven deployment of IFIT can be achieved.
>

KT2> I think we are talking specifics of this draft and not a common
approach. My understanding is the follows: IFIT encapsulating nodes are the
PE routers. These extensions are about signaling IFIT capabilities - i.e.
the capabilities of the PE routers. Then why do they need to be carried in
the service routes that are potentially several orders of magnitude larger
in scale than those corresponding to the PEs. What am I missing? Seems like
the draft is missing quite a lot?

Thanks,
Ketan

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 25 Mar 2022 07:25:56 +0000

Hi Ketan,
 Please check inline below with [SW2].

From: Ketan Talaulikar [mailto:[email-masked]]
Sent: Friday, March 25, 2022 11:56 AM
To: Zhuangshunwan <[email-masked]>
Cc: Tianran Zhou <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Shunwan,

On Fri, Mar 25, 2022 at 8:09 AM Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

Kind Regards,
Shunwan

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ketan Talaulikar
Sent: Thursday, March 24, 2022 10:47 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Tianran,

KT2> I think we are talking specifics of this draft and not a common approach. My understanding is the follows: IFIT encapsulating nodes are the PE routers. These extensions are about signaling IFIT capabilities - i.e. the capabilities of the PE routers. Then why do they need to be carried in the service routes that are potentially several orders of magnitude larger in scale than those corresponding to the PEs. What am I missing? Seems like the draft is missing quite a lot?

[SW2] IFIT deployment modes include node-level, tunnel-level, and service-level. While the current requirement is to provide IFIT deployment at service-level, since different services have different IFIT needs. The node-level and tunnel-level have also been considered, but they cannot meet the current needs. With the service-level solution, different IFIT modes can be deployed for different VPN services.

Thanks,
Shunwan

Thanks,
Ketan

Thanks,
Ketan

Many thanks,
Tianran

Hi Sue,

KT> Unable to determine.

Thanks,
Ketan

Cheerily, Sue

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 10:42:33 +0100

Zhuangshunwan,

I do not follow your logic.

You can still advertise ifit capability per node or per tunnel (effectively
per next hop) and have any service use subset of those as it seems fit for
the service.

There is no mandate that you must attach it with service routes at all.

As said earlier if you remove idea to propagate this with extended
community which is transitive and only limit it to non transitive next hop
attribute damaged will be contained and perhaps we could consider adoption.
Otherwise the blast radius is just too wide and adopting it encourages
implementations which may be very dangerous by polluting the Internet with
such ext comms leaking from some domains.

Thx,
R.

On Fri, Mar 25, 2022 at 8:26 AM Zhuangshunwan <zhuangshunwan=
[email-masked]> wrote:

> *From:* Ketan Talaulikar [mailto:[email-masked]]
> *Sent:* Friday, March 25, 2022 11:56 AM
> *To:* Zhuangshunwan <[email-masked]>
> *Cc:* Tianran Zhou <[email-masked]>; [email-masked]; Susan Hares <
> [email-masked]>
> [SW2] IFIT deployment modes include node-level, tunnel-level, and
> service-level. While the current requirement is to provide IFIT deployment
> at service-level, since different services have different IFIT needs. The
> node-level and tunnel-level have also been considered, but they cannot meet
> the current needs. With the service-level solution, different IFIT modes
> can be deployed for different VPN services.
>
>
>
> Thanks,
>
> Shunwan
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> Many thanks,
>
> Tianran
>
>
>

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 25 Mar 2022 10:05:17 +0000

Hi Robert,

The use of solutions should be designed and should not be used arbitrarily.
For this solution, it will mainly be used for VPN service. So I don’t think  it may cause leaking to Internet.
BTW, currently IANA has allocated a large number of EC attributes, does that mean we shouldn't continue to use EC attributes?

On the other hand, the author provides two extensions in this draft, and I think we should decide to choose one as the final implementation.

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, March 25, 2022 5:43 PM
To: Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Zhuangshunwan,

You can still advertise ifit capability per node or per tunnel (effectively per next hop) and have any service use subset of those as it seems fit for the service.

As said earlier if you remove idea to propagate this with extended community which is transitive and only limit it to non transitive next hop attribute damaged will be contained and perhaps we could consider adoption. Otherwise the blast radius is just too wide and adopting it encourages implementations which may be very dangerous by polluting the Internet with such ext comms leaking from some domains.

Thx,
R.

On Fri, Mar 25, 2022 at 8:26 AM Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,
 Please check inline below with [SW2].

From: Ketan Talaulikar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 25, 2022 11:56 AM
To: Zhuangshunwan <[email-masked]<mailto:[email-masked]>>
Cc: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Shunwan,

Kind Regards,
Shunwan

Hi Tianran,

Thanks,
Shunwan

Thanks,
Ketan

Thanks,
Ketan

Many thanks,
Tianran

Hi Sue,

KT> Unable to determine.

Thanks,
Ketan

Cheerily, Sue

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 25 Mar 2022 10:37:42 +0000

Hi all,

Regarding the description of the usage of the extended community attributes, we will revise it in the next version based on all your useful suggestions.
If the working group recommends, we can only keep the next hop attribute solution in new version. Resubmission of another draft containing only the extended community attributes in the future will depend on requirements.

Additional info:
Almost all current implementations have CLI knobs to control the announcement of the extended community attributes (ECA), by default they are not sending ECA to their peers unless we explicitly enabled knobs on each peer.
Maybe we don't have to worry about a lot of ECAs appearing in the Internet routing table?
Moreover, our solution is used in various VPN scenarios, and the possibility of leakage is very very low.

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Wanghaibo (Rainsword)
Sent: Friday, March 25, 2022 6:05 PM
To: Robert Raszuk <[email-masked]>; Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: [email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi Robert,

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, March 25, 2022 5:43 PM
To: Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:zhuangshunwan=[email-masked]>>
Cc: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Zhuangshunwan,

Thx,
R.

Hi Shunwan,

Kind Regards,
Shunwan

Hi Tianran,

Thanks,
Shunwan

Thanks,
Ketan

Thanks,
Ketan

Many thanks,
Tianran

Hi Sue,

KT> Unable to determine.

Thanks,
Ketan

Cheerily, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 26 Mar 2022 10:17:48 -0400

Greetings: 

The IDR chairs need to review the discussion here in depth prior to making a decision on this adoption call.   I will summarize the posts for this thread early next week, and indicate what questions I might have for IDR WG members.  

After we go through some Q/A, then the IDR chairs will discuss the results prior to making a decision.  It may be 2 weeks (4/8) before you get the final result.   Your feedback is welcome through-out this process.   We encourage discussions to continue on the list. 

Sue Hares

(IDR Chair Shepherd for adoption). 

From: Idr [mailto:[email-masked]] On Behalf Of Zhuangshunwan
Sent: Friday, March 25, 2022 6:38 AM
To: Wanghaibo (Rainsword); Robert Raszuk; Zhuangshunwan
Cc: [email-masked]; Susan Hares
Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04 (3/10 to 3/24)

Hi all,

Additional info:

Thanks,

Shunwan

Hi Robert,

Regards,

Haibo

Zhuangshunwan,

Thx,
R.

On Fri, Mar 25, 2022 at 8:26 AM Zhuangshunwan <zhuangshunwan=[email-masked]> wrote:

Hi Ketan,

Hi Shunwan,

 

On Fri, Mar 25, 2022 at 8:09 AM Zhuangshunwan <[email-masked]> wrote:

Hi Ketan,

Kind Regards,

Shunwan

Hi Tianran,

 

Hi Ketan,

            

Thanks,

Shunwan

Thanks,

Ketan

Thanks,

Ketan

Many thanks,

Tianran

Hi Sue,

 

KT> Unable to determine.

Thanks,

Ketan

Greeting: 

 

 

Cheerily, Sue