Re: [Last-Call] [Idr] Rtgdir last call review of draft-ietf-idr-bgp-open-policy-18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ines: 

Thank you for your careful and detailed review.   The authors will respond to you on the nits. 

Sue Hares  (chair, shepherd) 

-----Original Message-----
From: Idr [mailto:idr-bounces@xxxxxxxx] On Behalf Of Ines Robles via Datatracker
Sent: Wednesday, December 8, 2021 5:55 AM
To: rtg-dir@xxxxxxxx
Cc: draft-ietf-idr-bgp-open-policy.all@xxxxxxxx; idr@xxxxxxxx; last-call@xxxxxxxx
Subject: [Idr] Rtgdir last call review of draft-ietf-idr-bgp-open-policy-18

Reviewer: Ines Robles
Review result: Ready

Hello,

I have been selected to do a routing directorate review of this draft.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-idr-bgp-open-policy-18
Reviewer: Ines Robles
Review Date: 08-12-2021
Intended Status: Standards Track

Summary:

This document provides configuration automation using BGP Roles. An optional,
transitive BGP Path Attribute, called Only to Customer (OTC), is specified. It
prevents ASes from creating leaks and detects leaks created by the ASes in the
middle of an AS path.

This document is basically ready for publication, I have some minor
comments/questions below.

Major issues: None

Minor issues: None

Nits/Comments/Questions:

1- It would be nice to mention in the first paragraph of Section 4 when you
present the OTC Attribute that is included into the UPDATE message.

2- Should the attribute-flags of the OTC attribute mentioned explicitly in
Section 4? e.g. the high order bit (bit 0) is 1 (optional); the bit 1 is 1
(transitive); the bit 2 (partial bit) is 0/1(?), etc?

4- In Section 4,  the ingress policies guide to leak detection and the egress
policies guide to leak prevention. Correct?

5- Section 5: Is there a formal definition for complex peering relationships?
Should it be added into terminology section? Maybe defining what is a simple
peering relationship and then stating that what is not simple is complex?

How are the security considerations in complex peering relationships?

Thanks for this document,
Ines.


_______________________________________________
Idr mailing list
Idr@xxxxxxxx
https://www.ietf.org/mailman/listinfo/idr

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux