Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10
Hi Tim Thank you for your review and comments. See below PPE. On Thu, Nov 7, 2019 at 2:22 PM Tim Chown via Datatracker wrote: > Reviewer: Tim Chown > Review result: Has Nits > > I have reviewed this document as part of the Operational directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects > of > the IETF drafts. Comments that are not addressed in last call may be > included > in AD reviews during the IESG review. Document editors and WG chairs > should > treat these comments just like any other last call comments. > > The document describes a mechanism by which a node running OSPFv2 can repel > transit traffic if it is on the shortest path (and an alternative path > exists - > though this is not wholly clear in the document). It defines a Host-bit > (H-bit) > that allows the router to advertise that it is not a transit router, and it > describes the changes needed to support the H-bit within a domain, and > mitigations against potential routing loops. > > General comments: > > Should the document also state that it updates RFC 2328? > > PPE> No. This has been discussed previously during the AD review. This feature is an optional feature and RFC2328 does not require it for normal operations. > I think the document could be clearer on the behaviour when the H-bit and > MaxLinkMetric are used when there is only one path available, i.e. there > is no > redundant / alternative path. Section 4 of RFC 6987 implies that if there > is > only one path the router can still be used as a transit router, by the > nature > of the definition of MaxLinkMetric. The document has 3 or 4 places where > it > hints at behaviour, but I think it could be more explicit. > > PPE> This feature goes one step further than RFC 6987 which is a best effort at stopping transit traffic. We believe that the behavior is clear that a "host router" is NOT used for transit traffic regardless whether it is the last resort path or not. Please note the CURRENT version does not restrict the feature on a specific number of paths (last resort or not) or metric value (MaxlinkMetric or not) or make any assumption in that way. However, I proposed to add this text in an earlier thread to make it even more explicit. CURRENT: This document describes the Host-bit (H-bit) functionality that prevents other OSPFv2 routers from using the host router for transit traffic in OSPFv2 routing domains. SUGGESTED NEW: This document describes the Host-bit (H-bit) functionality that prevents other OSPFv2 routers from using the host router by excluding it in path calculations for transit traffic in OSPFv2 routing domains. > It may be worth explicitly stating that OSPFv3 is not mentioned due to it > having an R-bit defined for indicating whether a node/router can be used > for > transit traffic (see Sections 2.7 and A.2 of RFC 5340). > > PPE> There was an earlier discussions regarding mentioning the OSPFv3 functionality and eventually these references were removed in subsequent versions of the H-bit draft. The R-bit is not exactly the same as H-bit, even though both are used for the similar functionality, they rely on different mechanisms in the protocol. > The reasons given in Section 1 for the need for the H-bit are different to > those given in Section 1 of RFC 6987 for the capability. Should these be > more > consistent? Also, the document later mentions “a router being gracefully > isolated” as a reason, but this is not mentioned in Section 1. > > PPE> We believe that this the document covers this case in bullet 1 and bullet 3 in section1. CURRENT 1. To isolate a router to avoid blackhole scenarios when there is a reload and possible long reconvergence times. <...> 3. Overloaded routers could use such a capability to temporarily repel traffic until they stabilize. To make it even more explicit: SUGGESTION 1. To gracefully isolate a router to avoid blackhole scenarios when there is a reload and possible long reconvergence times. Let me know if this addresses all your comments Thanks Padma Nits: > > In the abstract: > Change > “This document defines a bit (Host-bit)” > to > “This document defines a Host bit (H-bit)” > for consistency > And “is a non-transit router.”” - remove the spurious “. > > Section 8: > Where it says “beyond those already known in OSPF”, say OSPFv2. > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10
Reviewer: Tim Chown Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes a mechanism by which a node running OSPFv2 can repel transit traffic if it is on the shortest path (and an alternative path exists - though this is not wholly clear in the document). It defines a Host-bit (H-bit) that allows the router to advertise that it is not a transit router, and it describes the changes needed to support the H-bit within a domain, and mitigations against potential routing loops. General comments: Should the document also state that it updates RFC 2328? I think the document could be clearer on the behaviour when the H-bit and MaxLinkMetric are used when there is only one path available, i.e. there is no redundant / alternative path. Section 4 of RFC 6987 implies that if there is only one path the router can still be used as a transit router, by the nature of the definition of MaxLinkMetric. The document has 3 or 4 places where it hints at behaviour, but I think it could be more explicit. It may be worth explicitly stating that OSPFv3 is not mentioned due to it having an R-bit defined for indicating whether a node/router can be used for transit traffic (see Sections 2.7 and A.2 of RFC 5340). The reasons given in Section 1 for the need for the H-bit are different to those given in Section 1 of RFC 6987 for the capability. Should these be more consistent? Also, the document later mentions “a router being gracefully isolated” as a reason, but this is not mentioned in Section 1. Nits: In the abstract: Change “This document defines a bit (Host-bit)” to “This document defines a Host bit (H-bit)” for consistency And “is a non-transit router.”” - remove the spurious “. Section 8: Where it says “beyond those already known in OSPF”, say OSPFv2. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [spring] IETF 106 - SPRING agenda
Thanks Robert, Nothing new on the bgp-ls being able to carry link state ;) - rfc7752 even states it.. “ .. a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol..” Thanks for sharing your initial thoughts on the proposal. Regards, Tarek From: Robert Raszuk Date: Thursday, November 7, 2019 at 4:52 AM To: Tarek Saad Cc: SPRING WG List , "lsr@ietf.org" Subject: Re: [spring] IETF 106 - SPRING agenda > Once advertised in the network using a suitable link state protocol > (such as OSPF, ISIS or BGP-LS), Whow ... never imagined that BGP-LS would be called one day a "link state protocol" and an equal sign would be made to OSPF and ISIS. Best, Robert. PS. As to the proposal in draft itself it is clearly possible - but then troubleshooting and operating such mixed network would be a simple nightmare. On Thu, Nov 7, 2019 at 3:25 AM Tarek Saad mailto:tsaad.@gmail.com>> wrote: Hi SPRING WG and Chairs, We would like to request a presentation time slot for - I-D: https://tools.ietf.org/html/draft-saad-sr-fa-link-00 - Speaker: Tarek Saad - Desired time: 10 minutes Regards, Tarek ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10
Hi Alvaro, Acee
Ack, I will spin a new version with the review comments and will add the
new bullet.
Thanks everyone for your valuable feedback and comments!
Padma
On Thu, Nov 7, 2019 at 9:06 AM Acee Lindem (acee) wrote:
> Hi Alvaro,
>
> On 11/7/19, 11:58 AM, "Alvaro Retana" wrote:
>
> On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:
>
> Padma:
>
> Hi!
>
> See below...
>
> > On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
> > > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault
> wrote:
> > > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
> > > > wrote:
> > > >
> > > > > * I'm curious what happens if a router sets the H-bit when it
> is on the
> > > > > only feasible transit path.
> > > >
> > > > PPE - The router with the H-bit set will not be "on the only
> feasible
> > > > transit path" to other destinations. The H-bit functionality
> will exclude
> > > > the host router from the path calculation in the SPF.
> > >
> > > I think you are talking about normal operation ("will not be on
> the only
> > > feasible transit path") and Kyle is asking about misconfiguration
> or
> > > similar edge cases.
> >
> > Thanks for this clarification.
> > >
> > > Having only read this email thread and not the document itself, I
> assume
> > > that traffic will fail to flow if such a misconfiguration
> occurred, but it
> > > would be good to confirm/refute that.
> >
> > Yes you are right ... for some cases.
> >
> > Assuming the router with the H-bit clear is on the only transit
> path. There
> > are several cases see below.
> >
> > Normal case:
> > The router has H-bit set
> > (a) All routers in the area support the H-bit then the router is
> excluded in
> > the SPF calculations and traffic will not flow.
> > (b) At least one router in the area does not support H-bit then
> H-bit is not
> > active in area. The traffic will flow as per normal OSPF operation.
> >
> > Misconfiguration case:
> > The router has H-bit erroneously set (misconfig)
> > (a) All routers in the areas support H-bit then the router is
> excluded in the
> > SPF calculations and traffic will not flow.
> > (b) At least one router in the area does not support H-bit then
> H-bit is not
> > active in area. The traffic will flow as per normal OSPF operation.
> >
> > The Section 8 of the document has a discussion on this.
>
> Yes, there is a discussion in §8, but I think we left out the case
> where a rogue router, who is on the only transit path, may set the
> H-bit (for no good/valid reason) and effectively partition the
> network. This case is indistinguishable from the normal case where
> the operator (still on the only transit path) may consciously decide
> to set the H-bit to perform maintenance, for example.
>
> Please add a new bullet to cover this case.
>
> If an OSPFv2 router is a trusted participant in the OSPFv2 routing domain
> (with or without cryptographic authentication), there are at least 3 or 4
> other ways in which it could partition the routing domain. This is just one
> more. However, I'm not opposed to adding the bullet as this is "what we do"
> during the security reviews.
>
> Thanks,
> Acee
>
>
> Thanks!
>
> Alvaro.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10
Hi Alvaro,
On 11/7/19, 11:58 AM, "Alvaro Retana" wrote:
On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:
Padma:
Hi!
See below...
> On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
> > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote:
> > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
> > > wrote:
> > >
> > > > * I'm curious what happens if a router sets the H-bit when it is on
the
> > > > only feasible transit path.
> > >
> > > PPE - The router with the H-bit set will not be "on the only feasible
> > > transit path" to other destinations. The H-bit functionality will
exclude
> > > the host router from the path calculation in the SPF.
> >
> > I think you are talking about normal operation ("will not be on the only
> > feasible transit path") and Kyle is asking about misconfiguration or
> > similar edge cases.
>
> Thanks for this clarification.
> >
> > Having only read this email thread and not the document itself, I assume
> > that traffic will fail to flow if such a misconfiguration occurred, but
it
> > would be good to confirm/refute that.
>
> Yes you are right ... for some cases.
>
> Assuming the router with the H-bit clear is on the only transit path.
There
> are several cases see below.
>
> Normal case:
> The router has H-bit set
> (a) All routers in the area support the H-bit then the router is excluded
in
> the SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is
not
> active in area. The traffic will flow as per normal OSPF operation.
>
> Misconfiguration case:
> The router has H-bit erroneously set (misconfig)
> (a) All routers in the areas support H-bit then the router is excluded in
the
> SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is
not
> active in area. The traffic will flow as per normal OSPF operation.
>
> The Section 8 of the document has a discussion on this.
Yes, there is a discussion in §8, but I think we left out the case
where a rogue router, who is on the only transit path, may set the
H-bit (for no good/valid reason) and effectively partition the
network. This case is indistinguishable from the normal case where
the operator (still on the only transit path) may consciously decide
to set the H-bit to perform maintenance, for example.
Please add a new bullet to cover this case.
If an OSPFv2 router is a trusted participant in the OSPFv2 routing domain (with
or without cryptographic authentication), there are at least 3 or 4 other ways
in which it could partition the routing domain. This is just one more. However,
I'm not opposed to adding the bullet as this is "what we do" during the
security reviews.
Thanks,
Acee
Thanks!
Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10
On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:
Padma:
Hi!
See below...
> On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
> > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote:
> > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
> > > wrote:
> > >
> > > > * I'm curious what happens if a router sets the H-bit when it is on the
> > > > only feasible transit path.
> > >
> > > PPE - The router with the H-bit set will not be "on the only feasible
> > > transit path" to other destinations. The H-bit functionality will exclude
> > > the host router from the path calculation in the SPF.
> >
> > I think you are talking about normal operation ("will not be on the only
> > feasible transit path") and Kyle is asking about misconfiguration or
> > similar edge cases.
>
> Thanks for this clarification.
> >
> > Having only read this email thread and not the document itself, I assume
> > that traffic will fail to flow if such a misconfiguration occurred, but it
> > would be good to confirm/refute that.
>
> Yes you are right ... for some cases.
>
> Assuming the router with the H-bit clear is on the only transit path. There
> are several cases see below.
>
> Normal case:
> The router has H-bit set
> (a) All routers in the area support the H-bit then the router is excluded in
> the SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is not
> active in area. The traffic will flow as per normal OSPF operation.
>
> Misconfiguration case:
> The router has H-bit erroneously set (misconfig)
> (a) All routers in the areas support H-bit then the router is excluded in the
> SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is not
> active in area. The traffic will flow as per normal OSPF operation.
>
> The Section 8 of the document has a discussion on this.
Yes, there is a discussion in §8, but I think we left out the case
where a rogue router, who is on the only transit path, may set the
H-bit (for no good/valid reason) and effectively partition the
network. This case is indistinguishable from the normal case where
the operator (still on the only transit path) may consciously decide
to set the H-bit to perform maintenance, for example.
Please add a new bullet to cover this case.
Thanks!
Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [spring] IETF 106 - SPRING agenda
*> Once advertised in the network using a suitable link state protocol > (such as OSPF, ISIS or BGP-LS),* Whow ... never imagined that BGP-LS would be called one day a "link state protocol" and an equal sign would be made to OSPF and ISIS. Best, Robert. PS. As to the proposal in draft itself it is clearly possible - but then troubleshooting and operating such mixed network would be a simple nightmare. On Thu, Nov 7, 2019 at 3:25 AM Tarek Saad wrote: > Hi SPRING WG and Chairs, > > > > We would like to request a presentation time slot for > > - I-D: https://tools.ietf.org/html/draft-saad-sr-fa-link-00 > > - Speaker: Tarek Saad > > - Desired time: 10 minutes > > > > Regards, > > Tarek > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
