Re: [pim] draft-ietf-pim-yang-03: questions

[Stig Venaas <[e-mail]>]

Hi

That sounds reasonable to me. So I assume we should do the same for PIM then.

Stig


On Wed, Jan 18, 2017 at 5:16 AM, Acee Lindem (acee) <[e-mail]> wrote:
> All,
>
> I spoke to Reshad Rahman (BFD YANG Model editor) regarding the BFD model
> yesterday and he assured me that the current model with the BFD session
> parameters centrally (as opposed to within the protocols) will be
> maintained. Consequently, I think OSPF can move to the IS-IS approach of a
> single BFD enabled interface leaf node conditioned with a BFD feature.
>
>
> Thanks,
> Acee
>
>
> On 1/13/17, 1:30 PM, "Derek Yeung" <[e-mail]> wrote:
>
>>OSPF model use augmentation module because of two reasons.
>>1) When OSPF first add BFD feature, the BFD model is not stable and we
>>want to isolate the OSPF base model from it.
>>2) It the earlier BFD model, the per protocol configuration is supported
>>and there is a BFD grouping (bfd-grouping-base-cfg-parms) that OSPF need
>>to use. See draft-zheng-bfd-yang-04.txt.
>>
>>The per-protocol configuration is later removed from BFD and hence from
>>OSPF BFD model, leaving it with a single boolean leaf.
>>If it is confident that the BFD model is now stable, we could change OSPF
>>model to use feature with single boolean leaf instead.
>>
>>Thanks,
>>Derek
>>
>>On 1/4/17, 9:35 AM, "Xufeng Liu" <[e-mail]> wrote:
>>
>>    During IETF at Seoul, this topic was brought to the attention of BFD
>>WG Chair, Jeff Haas ( cc'ed ). I think that BFD WG is currently working
>>on it, and will provide guidelines.
>>
>>    Thanks,
>>
>>    - Xufeng
>>
>>    > -----Original Message-----
>>    > From: Jeff Tantsura [mailto:[e-mail]]
>>    > Sent: Tuesday, January 3, 2017 8:23 PM
>>    > To: Stig Venaas <[e-mail]>; Toerless Eckert
>><[e-mail]>;
>>    > Acee Lindem (acee) <[e-mail]>; [e-mail]
>>    > Cc: [e-mail]; [e-mail]
>>    > Subject: Re: [pim] draft-ietf-pim-yang-03: questions
>>    >
>>    > Hi,
>>    >
>>    > I¹d like to align at least IGP¹s and PIM,
>>    >
>>    > ISIS ­ bfd is a feature
>>    > OSPF - defines module ietf-ospf-bfd
>>    >
>>    > bfd containers:
>>    > ospf:
>>    > container bfd {
>>    >          description "BFD configuration.";
>>    >          leaf enable {
>>    >            type boolean;
>>    >            default false;
>>    >
>>    > isis:
>>    > container bfd {
>>    >           if-feature bfd;
>>    >           leaf enable {
>>    >               type boolean;
>>    >               default false;
>>    >
>>    >  including Acee and Derek
>>    >
>>    > Cheers,
>>    > Jeff
>>    >
>>    >
>>    > On 1/3/17, 13:32, "pim on behalf of Stig Venaas"
>><[e-mail] on
>>    > behalf of [e-mail]> wrote:
>>    >
>>    >     Hi
>>    >
>>    >     I agree we need to figure these things out. pim is not in a
>>unique
>>    >     position here, YANG models for other routing protocols must be
>>facing
>>    >     the same questions. The bfd wg is working a model too, right?
>>Perhaps
>>    >     discuss it in the bfd wg and work with those working on the
>>model
>>    >     there?
>>    >
>>    >     Alternatively we could remove bfd from our models for now. They
>>could
>>    >     be added by a later RFC if a standard is needed.
>>    >
>>    >     Stig
>>    >
>>    >
>>    >     On Sun, Nov 13, 2016 at 6:16 PM, Toerless Eckert
>><[e-mail]> wrote:
>>    >     > To follow up on the questions i had on the mike on Seoul@PIM:
>>    >     >
>>    >     > Can you pls. point me to a place that defines how BFD has to
>>work if
>>    >     > two different protocols on the same interface are configured
>>for differrnt
>>    >     > local-multiplier, desired-min-tx, required-min-rx-interval
>>and the like.
>>    >     >
>>    >     > I hope thats specified in some BFD RFC/draft, but i couldn't
>>find it browsing
>>    >     > them.
>>    >     >
>>    >     > Also: In Seoul, it was said that some vendors have
>>configuration of these
>>    >     > parameters on a per-protocol basis. WOuld love a pointer
>>toward any single
>>    >     > vendor doc about that.
>>    >     >
>>    >     > If these parameters can be configured underneath a particular
>>protocol
>>    >     > (like PIM/BFD), why then should these parameters be "ro"
>>instead of "rw" ?
>>    >     >
>>    >     > Last but not least: Given how there is no PIM-BFD specific
>>"protocol spec"
>>    > out
>>    >     > of PIM or MBoned, it looks to me as if all this discussion is
>>probavbly better
>>    >     > done in BFD working group, and they should suggest the
>>parameters that
>>    >     > can be configured.
>>    >     >
>>    >     > draft-ietf-ospf-yang has a section about BFD which seems to
>>primarily
>>    >     > care about making OSPF-BFD in the OSPF-YANG model optional. I
>>think
>>    >     > it would be prudent to do the same for PIM-BFD. On the other
>>hand, even
>>    > the
>>    >     > OSPF-BFD definition does not seem to define these parameters.
>>So maybe
>>    >     > lets try to figur eout the best of what OSPF-BFD will
>>ultimately do
>>    >     > and then copy to PIM - unless we figure out reasons to go
>>beyond that
>>    > approach.
>>    >     >
>>    >     > Cheers
>>    >     >     Toerless
>>    >     >
>>    >     > _______________________________________________
>>    >     > pim mailing list
>>    >     > [e-mail]
>>    >     > https://www.ietf.org/mailman/listinfo/pim
>>    >
>>    >     _______________________________________________
>>    >     pim mailing list
>>    >     [e-mail]
>>    >     https://www.ietf.org/mailman/listinfo/pim
>>    >
>>    >
>>
>>
>>
>