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

Dear Jeff,

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

Best regards,
Shunwan

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Saturday, March 12, 2022 2:17 AM
> To: Susan Hares <shares@ndzh.com>
> Cc: idr@ietf.org
> Subject: Re: [Idr] Adoption call for draft-wang-idr-bgp-ifit-capabilities-04
> (3/10 to 3/24)
> 
> Sue and Working Group,
> 
> I'm generally supportive of IFIT for BGP.
> 
[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:
> 
> On Thu, Mar 10, 2022 at 09:38:43AM -0500, Susan Hares wrote:
> > 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?
> 
> >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.

[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
> of the IFIT domain.  What are the Security Considerations for such
> additional propagation of these Extended Communities?

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

> 
> I'm unclear whether the intent of the Extended Communities is whether they
> 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
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr