Re: [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

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

 



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.

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