Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Jeffrey Haas]

On Tue, Jun 20, 2017 at 02:48:51PM -0500, Greg Mirsky wrote:
> Hi Jeff,
> thank you for the great summary of the discussion, helps me to catch the
> wave.
> I'm skeptical that there's realistic scenario where two BFD systems will be
> requested to run multiple BFD single-hop session between them over the same
> interfaces (logical or physical). I believe that we should try to make
> models future proof but to the level that is reasonable, practical.
> Approach "if we can think of it, then we need to support it" may not be the
> one.
> RE: RFC 5881. I've referred to the following:
> ... any BFD packet from the remote machine with a zero value of Your
> Discriminator MUST be associated with the session bound to the remote
> system, interface, and protocol.
> Unless we add out-band bootstrapping of BFD sessions like with LSP Ping, I
> don't see how received BFD control packet with zero value in Your
> Discriminator may be bound to not just any one of several protocols that
> are trying to run BFD session on the same interface to the same remote
> system but to the right one, the one that corresponds to the protocol on
> whose behalf remote BFD peer sent the control packet. Hence my question Do
> we have implementation(s) that use this and are asking for BFD data model
> to accommodate them? Or we are just doing interesting intellectual exercise?

The constant iteration regarding "intellectual exercise" is getting
irritating.  See prior comments.

This distribution is too large to try to design the actual behavioral
change.  If you feel the need to pursue that thread, please reduce the scope
of the cc: list.  This will be my last reply to this topic on the expanded
distro.

To offer one example of how such a thing could be implemented, BFD
authentication can be used with different parameters for each session.  This
provides the necessary split for demultiplexing.  Such a hack is not unusual
operations trick when running OSPF for (partially) disjoint domains on the
same interface, although I suspect that the hack is no longer necessary with
multi-instance techs.  (This trick goes back to the 1990's.)

-- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Greg Mirsky]

Hi Jeff,
thank you for the great summary of the discussion, helps me to catch the
wave.
I'm skeptical that there's realistic scenario where two BFD systems will be
requested to run multiple BFD single-hop session between them over the same
interfaces (logical or physical). I believe that we should try to make
models future proof but to the level that is reasonable, practical.
Approach "if we can think of it, then we need to support it" may not be the
one.
RE: RFC 5881. I've referred to the following:
... any BFD packet from the remote machine with a zero value of Your
Discriminator MUST be associated with the session bound to the remote
system, interface, and protocol.
Unless we add out-band bootstrapping of BFD sessions like with LSP Ping, I
don't see how received BFD control packet with zero value in Your
Discriminator may be bound to not just any one of several protocols that
are trying to run BFD session on the same interface to the same remote
system but to the right one, the one that corresponds to the protocol on
whose behalf remote BFD peer sent the control packet. Hence my question Do
we have implementation(s) that use this and are asking for BFD data model
to accommodate them? Or we are just doing interesting intellectual exercise?

Regards,
Greg

On Tue, Jun 20, 2017 at 2:00 PM, Jeffrey Haas  wrote:

> Greg,
>
> On Tue, Jun 20, 2017 at 12:55:58PM -0500, Greg Mirsky wrote:
> > Hi Jeff,
> > I'd like to hear from others who are familiar with implementations of BFD
> > that supports per protocol single-hop BFD multi-sessions between the same
> > pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions
> > on the same interface, logical or physical, between the same pair of
> > systems. But it is not clear, in my opinion, how BFD does demultiplexing
> if
> > Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence)
> > if systems use the same IP addresses. And hence the question, Even though
> > it is allowed to have BFD single-hop sessions per application/protocol on
> > the same interface between the same pair of systems, is this real,
> > practical requirement?
> > Or am I missing the point completely?
>
> Correct, 5881 procedures do not currently permit this.
> As I mentioned, we've had prior discussions about this being potentially
> problematic for clients that may have differing timing requirements.
>
> Part of the point of this exercise is to provide necessary future-proofing
> against the need to re-issue the Yang modules if such a mechanism is
> developed.  (Somewhat analogous to the instructions to the design team that
> MPLS-TP was out of scope for the module, but that its structure shouldn't
> prevent its implementation in the future.)
>
> Thus far, two points have sprung from the discussion that are likely
> actionable:
> - The single-hop configuration in the current BFD module isn't suitable for
>   use by the IGPs.  Some form of wildcard of templating behavior is
>   necessary.
> - Multiple clients that might desire to configure a session with different
>   parameters are unable to do so today.  This precludes some
> implementations
>   that permit such configuration, potentially at protocol scope.  It also
>   doesn't fit the future-proofing thought.
>
>
> -- Jeff
>
> >
> > Regards,
> > Greg
> >
> > On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas  wrote:
> >
> > > [Long delayed response.]
> > >
> > > Reshad picked up the key points: Some things may make sense in the
> > > per-client (protocol) users of BFD, some things perhaps do not.  And
> some
> > > come down to questions for timer granularity.
> > >
> > > The OSPF and ISIS models both make use of BFD simply by providing a
> boolean
> > > that says "I'm using BFD or not".
> > >
> > > Where we run into some issues are the cases highlighted: when the
> sessions
> > > don't share common properties, how should the protocol pick what BFD
> > > session
> > > to use?
> > >
> > > The current BFD yang model only permits a single IP single-hop session
> > > to be configured.  (Key is interface/dst-ip)  This means that if
> different
> > > parameters *were* desired, the BFD model won't permit it today.
> However,
> > > BFD sessions for many protocols tend not to be configured, but may
> spring
> > > forth from protocol state, such as IGP adjacencies.  Thus, it's not
> > > "configured" - it's solely operational state.  However, the BFD yang
> model
> > > doesn't really make good provision for that as an "on".
> > >
> > > Where all endpoint state is known a priori, config state makes better
> > > sense.
> > >
> > > To pick the example of Juniper's configuration, if OSPF and eBGP were
> using
> > > BFD, both can choose differing timers.  This represents two pieces of
> > > configuration state for the same endpoints.  Additionally, only one BFD
> > > session is formed using the most aggressive timers.
> > >
> > > I partially point out the situation of multiple timers since there 

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Jeffrey Haas]

Greg,

On Tue, Jun 20, 2017 at 12:55:58PM -0500, Greg Mirsky wrote:
> Hi Jeff,
> I'd like to hear from others who are familiar with implementations of BFD
> that supports per protocol single-hop BFD multi-sessions between the same
> pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions
> on the same interface, logical or physical, between the same pair of
> systems. But it is not clear, in my opinion, how BFD does demultiplexing if
> Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence)
> if systems use the same IP addresses. And hence the question, Even though
> it is allowed to have BFD single-hop sessions per application/protocol on
> the same interface between the same pair of systems, is this real,
> practical requirement?
> Or am I missing the point completely?

Correct, 5881 procedures do not currently permit this.
As I mentioned, we've had prior discussions about this being potentially
problematic for clients that may have differing timing requirements.

Part of the point of this exercise is to provide necessary future-proofing
against the need to re-issue the Yang modules if such a mechanism is
developed.  (Somewhat analogous to the instructions to the design team that
MPLS-TP was out of scope for the module, but that its structure shouldn't
prevent its implementation in the future.)

Thus far, two points have sprung from the discussion that are likely
actionable:
- The single-hop configuration in the current BFD module isn't suitable for
  use by the IGPs.  Some form of wildcard of templating behavior is
  necessary.
- Multiple clients that might desire to configure a session with different
  parameters are unable to do so today.  This precludes some implementations
  that permit such configuration, potentially at protocol scope.  It also
  doesn't fit the future-proofing thought.


-- Jeff

> 
> Regards,
> Greg
> 
> On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas  wrote:
> 
> > [Long delayed response.]
> >
> > Reshad picked up the key points: Some things may make sense in the
> > per-client (protocol) users of BFD, some things perhaps do not.  And some
> > come down to questions for timer granularity.
> >
> > The OSPF and ISIS models both make use of BFD simply by providing a boolean
> > that says "I'm using BFD or not".
> >
> > Where we run into some issues are the cases highlighted: when the sessions
> > don't share common properties, how should the protocol pick what BFD
> > session
> > to use?
> >
> > The current BFD yang model only permits a single IP single-hop session
> > to be configured.  (Key is interface/dst-ip)  This means that if different
> > parameters *were* desired, the BFD model won't permit it today.  However,
> > BFD sessions for many protocols tend not to be configured, but may spring
> > forth from protocol state, such as IGP adjacencies.  Thus, it's not
> > "configured" - it's solely operational state.  However, the BFD yang model
> > doesn't really make good provision for that as an "on".
> >
> > Where all endpoint state is known a priori, config state makes better
> > sense.
> >
> > To pick the example of Juniper's configuration, if OSPF and eBGP were using
> > BFD, both can choose differing timers.  This represents two pieces of
> > configuration state for the same endpoints.  Additionally, only one BFD
> > session is formed using the most aggressive timers.
> >
> > I partially point out the situation of multiple timers since there have
> > been
> > prior list discussions on the situation where clients have different timing
> > requirements.  I don't think we handle this operationally in the BFD
> > protocol in the cleanest fashion right now - the session will go to Down
> > when the aggressive timers fail and there's no clean way to renegotiate to
> > the less aggressive timers.
> >
> > -- Jeff
> >
> >
> >
> >
> >
> >
> > On Fri, May 19, 2017 at 02:31:38AM +, Reshad Rahman (rrahman) wrote:
> > > We started off with the intent of having BFD parameters in the
> > applications/protocols which make use of BFD. For timer/multiplier this is
> > pretty straight-forward, although the discussion of what to do when not all
> > applications have the same BFD parameters for the same session (e.g. Go
> > with most aggressive etc). Then we started looking at authentication
> > parameters and having BFD authentication parms in OSPF/ISIS etc is not
> > intuitive. And what do we do if applications have different BFD
> > authentication parms. We concluded that the BFD authentication parms were
> > better off in BFD. And once we did that, the timer/multiplier followed
> > >
> > > I may not recall all the details/discussons, but I do recall that we
> > went back and forth on this and it took some time to make the decision.
> > >
> > > Regards,
> > > Reshad (as individual contributor).
> > >
> > > From: Mahesh Jethanandani  mjethanand...@gmail.com>>
> > > Date: Thursday, May 18, 2017 at 5:34 PM
> > > 

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Acee Lindem (acee)]

On 6/20/17, 1:50 PM, "Mahesh Jethanandani"  wrote:

>
>> On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee)  wrote:
>> 
>> Hi Jeff, 
>> 
>> On 6/20/17, 10:58 AM, "Jeffrey Haas"  wrote:
>> 
>>> Les,
>>> 
>>> On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg)
>>>wrote:
> Different protocols have different survivability requirements.  An
 IGP may
> very well want sub-second timers, potentially for repair behaviors.
 BGP may
> want fast failover, but may be fine with second level granularity.
 This is
> particularly true since the cost of too aggressively flapping BGP is
 of
> significantly greater impact to the network and the router.
> 
 [Les:] The real issues here are false failures and proper use of
 dampening. No protocol - not even an IGP - wants to flap
unnecessarily.
 If timers are set so aggressively that false failures are reported
this
 is BAD.
 Even worse is failure to dampen so that we get multiple false failures
 in a short period of time.
 
 Arguing that the right way to solve this problem is to increase the
 number of sessions using different timer granularity seems likely to
 make any problems worse as you have now increased the number of BFD
 sessions with the associated costs.
>>> 
>>> I'm mildly amused you seem to think I'm not considering the cost of
>>> additional sessions in the scaling matrix. :-)
>>> 
>>> I do think you're conflating the survivability requirements vs. timer
>>> granularity.  However, I agree that the most commonly deployed form is
>>>to
>>> go
>>> for single session with the most stable aggressive timer.
>>> 
>>> Again, the reason I raise this is there has been discussion regarding
>>> behavior for different client timing requirements.  There are a few
>>> options
>>> for how this is likely to play out in terms of BFD protocol
>>> implementation.
>>> However, configuration and operational models tend to evolve much more
>>> slowly.  (And I certainly don't need to tell you that.)  Thus, I'm
>>> prodding
>>> at this space a bit to attempt to do some future proofing.
>>> 
>>> As we noted earlier in thread, this likely at least encourages
>>> configuration
>>> to be multi-instanced, even if the session instantiation is not
>>>currently.
>>> Key changes aren't something we can readily do, so getting that part
>>>right
>>> early is necessary.
>>> 
>>> The likely impact on current IGP module BFD configuration may be a
>>>later
>>> augmentation.  Thus, as long as the likely implications are understood,
>>> there may be no further action needed at this time.  Determining that
>>>is
>>> partially what this thread is attempting to shake out.
>> 
>> In the IGPs, we have a separate BFD container in the interface
>> configuration. Currently, it only contains the a boolean. This could
>> easily be augmented to reference the appropriate construct in the BFD
>> model. 
>
>Let me work with Reshad to suggest what IGP could suggest to BFD in their
>construct, and have BFP pick what it believes would be the right set of
>parameters to be able to support most of the IGPs over the given BFD
>session. Whether we add it in the current model or add it later as an
>augmentation could then be decided separately.

Given that the IGP models are more mature and will soon be ready for
publication, I think it is a given that this will be done in an
augmentation. 

Thanks,
Acee 


>
>> 
>> Thanks,
>> Acee 
>> 
>> 
>>> 
>>> -- Jeff
>> 
>
>Mahesh Jethanandani
>mjethanand...@gmail.com
>

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Greg Mirsky]

Hi Jeff,
I'd like to hear from others who are familiar with implementations of BFD
that supports per protocol single-hop BFD multi-sessions between the same
pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions
on the same interface, logical or physical, between the same pair of
systems. But it is not clear, in my opinion, how BFD does demultiplexing if
Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence)
if systems use the same IP addresses. And hence the question, Even though
it is allowed to have BFD single-hop sessions per application/protocol on
the same interface between the same pair of systems, is this real,
practical requirement?
Or am I missing the point completely?

Regards,
Greg

On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas  wrote:

> [Long delayed response.]
>
> Reshad picked up the key points: Some things may make sense in the
> per-client (protocol) users of BFD, some things perhaps do not.  And some
> come down to questions for timer granularity.
>
> The OSPF and ISIS models both make use of BFD simply by providing a boolean
> that says "I'm using BFD or not".
>
> Where we run into some issues are the cases highlighted: when the sessions
> don't share common properties, how should the protocol pick what BFD
> session
> to use?
>
> The current BFD yang model only permits a single IP single-hop session
> to be configured.  (Key is interface/dst-ip)  This means that if different
> parameters *were* desired, the BFD model won't permit it today.  However,
> BFD sessions for many protocols tend not to be configured, but may spring
> forth from protocol state, such as IGP adjacencies.  Thus, it's not
> "configured" - it's solely operational state.  However, the BFD yang model
> doesn't really make good provision for that as an "on".
>
> Where all endpoint state is known a priori, config state makes better
> sense.
>
> To pick the example of Juniper's configuration, if OSPF and eBGP were using
> BFD, both can choose differing timers.  This represents two pieces of
> configuration state for the same endpoints.  Additionally, only one BFD
> session is formed using the most aggressive timers.
>
> I partially point out the situation of multiple timers since there have
> been
> prior list discussions on the situation where clients have different timing
> requirements.  I don't think we handle this operationally in the BFD
> protocol in the cleanest fashion right now - the session will go to Down
> when the aggressive timers fail and there's no clean way to renegotiate to
> the less aggressive timers.
>
> -- Jeff
>
>
>
>
>
>
> On Fri, May 19, 2017 at 02:31:38AM +, Reshad Rahman (rrahman) wrote:
> > We started off with the intent of having BFD parameters in the
> applications/protocols which make use of BFD. For timer/multiplier this is
> pretty straight-forward, although the discussion of what to do when not all
> applications have the same BFD parameters for the same session (e.g. Go
> with most aggressive etc). Then we started looking at authentication
> parameters and having BFD authentication parms in OSPF/ISIS etc is not
> intuitive. And what do we do if applications have different BFD
> authentication parms. We concluded that the BFD authentication parms were
> better off in BFD. And once we did that, the timer/multiplier followed
> >
> > I may not recall all the details/discussons, but I do recall that we
> went back and forth on this and it took some time to make the decision.
> >
> > Regards,
> > Reshad (as individual contributor).
> >
> > From: Mahesh Jethanandani >
> > Date: Thursday, May 18, 2017 at 5:34 PM
> > To: "Acee Lindem (acee)" >
> > Cc: Jeffrey Haas >, OSPF WG
> List >, "draft-ietf-bfd-y...@ietf.org<
> mailto:draft-ietf-bfd-y...@ietf.org>"  mailto:draft-ietf-bfd-y...@ietf.org>>, "draft-ietf-ospf-y...@ietf.org
> "  >, "rtg-...@ietf.org b...@ietf.org>" >
> > Subject: Re: IETF OSPF YANG and BFD Configuration
> > Resent-From: >
> > Resent-To: >,
> Reshad >, <
> mjethanand...@gmail.com>, <
> santosh.pallaga...@gmail.com>, <
> gregimir...@gmail.com>
> > Resent-Date: Thursday, May 18, 2017 at 5:40 PM
> >
> > Resending with correct BFD WG address.
> >
> > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani <
> mjethanand...@gmail.com> wrote:
> >
> > Agree with Acee's assessment. After much debate, 

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Mahesh Jethanandani]

> On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee)  wrote:
> 
> Hi Jeff, 
> 
> On 6/20/17, 10:58 AM, "Jeffrey Haas"  wrote:
> 
>> Les,
>> 
>> On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg) wrote:
 Different protocols have different survivability requirements.  An
>>> IGP may
 very well want sub-second timers, potentially for repair behaviors.
>>> BGP may
 want fast failover, but may be fine with second level granularity.
>>> This is
 particularly true since the cost of too aggressively flapping BGP is
>>> of
 significantly greater impact to the network and the router.
 
>>> [Les:] The real issues here are false failures and proper use of
>>> dampening. No protocol - not even an IGP - wants to flap unnecessarily.
>>> If timers are set so aggressively that false failures are reported this
>>> is BAD.
>>> Even worse is failure to dampen so that we get multiple false failures
>>> in a short period of time.
>>> 
>>> Arguing that the right way to solve this problem is to increase the
>>> number of sessions using different timer granularity seems likely to
>>> make any problems worse as you have now increased the number of BFD
>>> sessions with the associated costs.
>> 
>> I'm mildly amused you seem to think I'm not considering the cost of
>> additional sessions in the scaling matrix. :-)
>> 
>> I do think you're conflating the survivability requirements vs. timer
>> granularity.  However, I agree that the most commonly deployed form is to
>> go
>> for single session with the most stable aggressive timer.
>> 
>> Again, the reason I raise this is there has been discussion regarding
>> behavior for different client timing requirements.  There are a few
>> options
>> for how this is likely to play out in terms of BFD protocol
>> implementation.
>> However, configuration and operational models tend to evolve much more
>> slowly.  (And I certainly don't need to tell you that.)  Thus, I'm
>> prodding
>> at this space a bit to attempt to do some future proofing.
>> 
>> As we noted earlier in thread, this likely at least encourages
>> configuration
>> to be multi-instanced, even if the session instantiation is not currently.
>> Key changes aren't something we can readily do, so getting that part right
>> early is necessary.
>> 
>> The likely impact on current IGP module BFD configuration may be a later
>> augmentation.  Thus, as long as the likely implications are understood,
>> there may be no further action needed at this time.  Determining that is
>> partially what this thread is attempting to shake out.
> 
> In the IGPs, we have a separate BFD container in the interface
> configuration. Currently, it only contains the a boolean. This could
> easily be augmented to reference the appropriate construct in the BFD
> model. 

Let me work with Reshad to suggest what IGP could suggest to BFD in their 
construct, and have BFP pick what it believes would be the right set of 
parameters to be able to support most of the IGPs over the given BFD session. 
Whether we add it in the current model or add it later as an augmentation could 
then be decided separately.

> 
> Thanks,
> Acee 
> 
> 
>> 
>> -- Jeff
> 

Mahesh Jethanandani
mjethanand...@gmail.com

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Acee Lindem (acee)]

Hi Jeff, 

On 6/20/17, 10:58 AM, "Jeffrey Haas"  wrote:

>Les,
>
>On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg) wrote:
>> > Different protocols have different survivability requirements.  An
>>IGP may
>> > very well want sub-second timers, potentially for repair behaviors.
>>BGP may
>> > want fast failover, but may be fine with second level granularity.
>>This is
>> > particularly true since the cost of too aggressively flapping BGP is
>>of
>> > significantly greater impact to the network and the router.
>> > 
>> [Les:] The real issues here are false failures and proper use of
>>dampening. No protocol - not even an IGP - wants to flap unnecessarily.
>>If timers are set so aggressively that false failures are reported this
>>is BAD.
>> Even worse is failure to dampen so that we get multiple false failures
>>in a short period of time.
>> 
>> Arguing that the right way to solve this problem is to increase the
>>number of sessions using different timer granularity seems likely to
>>make any problems worse as you have now increased the number of BFD
>>sessions with the associated costs.
>
>I'm mildly amused you seem to think I'm not considering the cost of
>additional sessions in the scaling matrix. :-)
>
>I do think you're conflating the survivability requirements vs. timer
>granularity.  However, I agree that the most commonly deployed form is to
>go
>for single session with the most stable aggressive timer.
>
>Again, the reason I raise this is there has been discussion regarding
>behavior for different client timing requirements.  There are a few
>options
>for how this is likely to play out in terms of BFD protocol
>implementation.
>However, configuration and operational models tend to evolve much more
>slowly.  (And I certainly don't need to tell you that.)  Thus, I'm
>prodding
>at this space a bit to attempt to do some future proofing.
>
>As we noted earlier in thread, this likely at least encourages
>configuration
>to be multi-instanced, even if the session instantiation is not currently.
>Key changes aren't something we can readily do, so getting that part right
>early is necessary.
>
>The likely impact on current IGP module BFD configuration may be a later
>augmentation.  Thus, as long as the likely implications are understood,
>there may be no further action needed at this time.  Determining that is
>partially what this thread is attempting to shake out.

In the IGPs, we have a separate BFD container in the interface
configuration. Currently, it only contains the a boolean. This could
easily be augmented to reference the appropriate construct in the BFD
model. 

Thanks,
Acee 


>
>-- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

[Alia Atlas]

On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu  wrote:

> Hi Alia,
>
>
>
> Thanks a lot for your AD review. Please see our response inline.
>
>
>
> *发件人**:* Alia Atlas [mailto:akat...@gmail.com ]
> *发送时间**:* 2017年6月15日 6:56
> *收件人**:* OSPF List; draft-ietf-ospf-encapsulation-...@ietf.org
> *主题**:* AD review of draft-ietf-ospf-encapsulation-cap-03
>
>
>
> As is customary, I have done my AD review of draft-ietf-ospf-
> encapsulation-cap-03.
>
> First, I would like to thank the authors - Xiaohu, Bruno, Robert, Luis,
> and Luay - for their work on this useful document.
>
>
>
> I do have a few concerns that need addressing before the draft can
> progress.
>
>
>
> [Bruno/Xiaohu] Many thanks for your useful comments.
>
> Following your comments, we believe it would be simpler and better to not
> create a new IANA registry for ”IGP  Tunnel Encapsulation Attribute Types”
> but rather reuse the existing BGP one:
>
> https://www.iana.org/assignments/bgp-parameters/
> bgp-parameters.xhtml#tunnel-types
>

Given that the sub-TLVs available depend on the tunnel type, I think this
makes sense.



> [Bruno/Xiaohu] BTW when this OSPF extension has been defined, it has been
> modeled based on RFC 5512. However, as of today, the BGP extension is been
> redefined in draft-ietf-idr-tunnel-encaps, sometimes. Which normative
> reference should be use?
>
> - as of today, RFC 5512 is probably the right one as
> draft-ietf-idr-tunnel-encaps has not passed WG LC and may never be
> published as RFC (IDR requires 2 implementations. I think RFC 5512 has not
> been implemented hence we may question whether draft-ietf-idr-tunnel-encaps
> will be…)
>
> - in some hypothetical future, draft-ietf-idr-tunnel-encaps may obsolete
> RFC 5512
>

Judging from the two partial implementations in the IDR wiki, I'm not quite
as concerned.  That said, are you certain that there aren't explanations
and behaviors that are clarified in draft-ietf-idr-tunnel-encaps that
aren't in RFC 5512?  Certainly, some of the tunnel types that were
mentioned in the OSPF registry are from the former.


> Major:
>
>
>
> 1)  First, the draft talks about what information is sent - but nothing
> about how it is to be understood or used.  That'd be ok if there were a
> clear reference to a document that discussed the related procedures.  A
> quick scan of draft-ietf-idr-tunnel-encaps-06 seems that it may be the
> right place to start - but it's procedures are BGP-focused and while there
> are many similarities, there may be interesting differences as well.
>
>
>
> [Bruno/Xiaohu] We’ll clarify that the 3 sub-TLV (§5.1-§5.3) are
> normatively defined in RFC 5512, from a format, semantic and usage
> standpoint. And that there code point are allocated in respectively the
> following IANA registries: BGP Tunnel Encapsulation Attribute Tunnel Types,
> BGP Tunnel Encapsulation Attribute Sub-TLVs. As per you comment, we need to
> clarify the 5.4 color Sub-TLV. Proposed text:
>
> The Color Sub-TLV value is a 4-octet unsigned integer. Its semantic and
> usage are the same as the Color Value, from the Color Sub-TLV defined in
> RFC 5512 section 4.3 (*)
>
>
>
> For instance, for the Color sub-TLV, is the 4 byte color value expected to
> represent the same meaning in OSPF as in BGP?
>
>
>
> [Bruno/Xiaohu]Yes.
>
>
>
>   Can a BGP route with a particular color extended community then have the
> OSPF tunnel to use selected from only those tunnels with the same color?
>
>
>
>   What does the Color TLV mean in a purely OSPF context?
>
>
>
> [Bruno/Xiaohu] idem as in the IDR context.  It’s a color used to define
> policy. The application using those tunnels, may use this color as an input
> for its policy when choosing the tunnel to use (or not use).
>
> We can add this text if needed.
>
>
Yes, I think that is needed.  In BGP, since a route can have communities,
it is easy to just have a "must match color" rule (though one could picture
a community that means match-any-tunnel-but-this-color).  For OSPF, if the
intention of the use for this information is an external application, that
needs to be clearly stated.

There needs to be enough text so that two implementations can actually use
the functionality - not merely signal it - and that is generally what is
missing in the document.

   Sec 7 of draft-ietf-idr-tunnel-encaps-06 ("However, suppose that one of
> the TLVs in U2's Tunnel Encapsulation attribute contains the Color
> Sub-TLV.  In that case, packet P SHOULD
>
>NOT be sent through the tunnel identified in that TLV, unless U1 is
>carrying the Color Extended Community that is identified in U2's
>Color Sub-TLV.") doesn't seem to strictly apply.
>
>
>
> [Bruno/Xiaohu] Would new clarification added above (*) be enough? If not,
> a priori, I’d rather improve the definition of section 5.4 defining this
> color sub-TLV, in order for it to generally apply to any text. (rather than
> trying to patch the specific above text from Sec 7)
>

I would be 

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Jeffrey Haas]

Les,

On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg) wrote:
> > Different protocols have different survivability requirements.  An IGP may
> > very well want sub-second timers, potentially for repair behaviors.  BGP may
> > want fast failover, but may be fine with second level granularity.  This is
> > particularly true since the cost of too aggressively flapping BGP is of
> > significantly greater impact to the network and the router.
> > 
> [Les:] The real issues here are false failures and proper use of dampening. 
> No protocol - not even an IGP - wants to flap unnecessarily. If timers are 
> set so aggressively that false failures are reported this is BAD.
> Even worse is failure to dampen so that we get multiple false failures in a 
> short period of time.
> 
> Arguing that the right way to solve this problem is to increase the number of 
> sessions using different timer granularity seems likely to make any problems 
> worse as you have now increased the number of BFD sessions with the 
> associated costs.

I'm mildly amused you seem to think I'm not considering the cost of
additional sessions in the scaling matrix. :-)

I do think you're conflating the survivability requirements vs. timer
granularity.  However, I agree that the most commonly deployed form is to go
for single session with the most stable aggressive timer.

Again, the reason I raise this is there has been discussion regarding
behavior for different client timing requirements.  There are a few options
for how this is likely to play out in terms of BFD protocol implementation.
However, configuration and operational models tend to evolve much more
slowly.  (And I certainly don't need to tell you that.)  Thus, I'm prodding
at this space a bit to attempt to do some future proofing.

As we noted earlier in thread, this likely at least encourages configuration
to be multi-instanced, even if the session instantiation is not currently.
Key changes aren't something we can readily do, so getting that part right
early is necessary.

The likely impact on current IGP module BFD configuration may be a later
augmentation.  Thus, as long as the likely implications are understood,
there may be no further action needed at this time.  Determining that is
partially what this thread is attempting to shake out.

-- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Les Ginsberg (ginsberg)]

Jeff -

Inline.

> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, June 20, 2017 7:17 AM
> To: Mahesh Jethanandani
> Cc: Jeffrey Haas; Reshad Rahman (rrahman); OSPF WG List; draft-ietf-ospf-
> y...@ietf.org; rtg-...@ietf.org; draft-ietf-bfd-y...@ietf.org; Acee Lindem
> (acee)
> Subject: Re: IETF OSPF YANG and BFD Configuration
> 
> Mahesh,
> 
> On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote:
> > > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas  wrote:
> > > Where we run into some issues are the cases highlighted: when the
> > > sessions don't share common properties, how should the protocol pick
> > > what BFD session to use?
> >
> > The issue that I hear most is the timer granularity. Is there something 
> > else?
> 
> Potentially mode (async vs. echo) and authentication.  However, I believe
> timer granularity is the biggest one.
> 
> > > The current BFD yang model only permits a single IP single-hop
> > > session to be configured.  (Key is interface/dst-ip)  This means
> > > that if different parameters *were* desired, the BFD model won't
> > > permit it today.  However, BFD sessions for many protocols tend not
> > > to be configured, but may spring forth from protocol state, such as
> > > IGP adjacencies.  Thus, it's not "configured" - it's solely
> > > operational state.  However, the BFD yang model doesn't really make
> good provision for that as an "on”.
> >
> > The idea is that a BFD session is configured a priori and before a IGP 
> > session
> is configured with the most aggressive timer. IGP sessions then refer to the
> BGP session configured. If a IGP session is added that requires a more
> aggressive timer, we would have to renegotiate the more aggressive timer
> value.
> 
> Consider a broadcast network segment such as Ethernet.
> Consider a few dozen routers on such a segment.
> 
> Is it your expectation that an IGP would require each of those routers to be
> manually configured in the Yang module a priori?  That is, after all, much of
> the point of an IGP: automatic discovery.
> 
> > > Where all endpoint state is known a priori, config state makes better
> sense.
> > >
> > > To pick the example of Juniper's configuration, if OSPF and eBGP
> > > were using BFD, both can choose differing timers.  This represents
> > > two pieces of configuration state for the same endpoints.
> > > Additionally, only one BFD session is formed using the most aggressive
> timers.
> >
> > That is what we are suggesting also.
> 
> The distinguishing point is configuration vs. operational state.  The current
> model doesn't permit more than one set of parameters to be provisioned
> even if the implementation may choose to instantiate exactly one session.
> 
> > > I partially point out the situation of multiple timers since there
> > > have been prior list discussions on the situation where clients have
> > > different timing requirements.  I don't think we handle this
> > > operationally in the BFD protocol in the cleanest fashion right now
> > > - the session will go to Down when the aggressive timers fail and
> > > there's no clean way to renegotiate to the less aggressive timers.
> >
> > A BFD session would fail more likely because there is a real network failure
> than because the timer was more aggressive than what IGP had requested.
> 
> Please note that I raise this point mostly because of prior discussion.  I'm 
> well
> aware of the headaches this currently causes:
> 
> Different protocols have different survivability requirements.  An IGP may
> very well want sub-second timers, potentially for repair behaviors.  BGP may
> want fast failover, but may be fine with second level granularity.  This is
> particularly true since the cost of too aggressively flapping BGP is of
> significantly greater impact to the network and the router.
> 
[Les:] The real issues here are false failures and proper use of dampening. No 
protocol - not even an IGP - wants to flap unnecessarily. If timers are set so 
aggressively that false failures are reported this is BAD.
Even worse is failure to dampen so that we get multiple false failures in a 
short period of time.

Arguing that the right way to solve this problem is to increase the number of 
sessions using different timer granularity seems likely to make any problems 
worse as you have now increased the number of BFD sessions with the associated 
costs.

   Les

> But moving to what *is* rather than what should be, if there are two
> different timing setups for the same endpoint: If you deprovision the more
> aggressive timer, the session should likely renegotiate to the less aggressive
> one rather than drop.
> 
> -- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Acee Lindem (acee)]

Jeff, 

On 6/20/17, 10:20 AM, "Jeffrey Haas"  wrote:

>Acee,
>
>On Mon, Jun 19, 2017 at 10:10:43PM +, Acee Lindem (acee) wrote:
>> I don’t really feel there is a strong requirement to support different
>> timers values per protocol even though several implementations allow
>> different protocol specific values to be configured (with varying
>> behaviors). 
>> 
>> If there were such a requirement, I would think it would be better
>> satisfied by extending the BFD model session key with an additional
>> identifier, e.g., .
>
>I suspect multi-instancing may be where this conversation goes.
>
>> IMO, this would be
>> preferable to allowing the details of BFD to permeate into all the other
>> protocol models. This would require configuration of the instance rather
>> than a boolean in the protocols.
>
>My lingering concern is whether the client protocol may have preferences
>about what session to use when such multi-instancing is permitted.
>Minimally this would require some sort of Yang reference to the specific
>instance.

Right - this is what I just said.
>
>As I'm noting in the other response, do we really expect BFD Yang model
>users to pre-provision every single OSPF/ISIS adjacency in the config
>stanza?  Likely, no.

Agreed. 
>
>What I tend to expect is a template being used for a service profile.  We
>don't currently have such a thing.

Agreed. My point is that the BFD specific parameters should in the BFD
model rather than the protocol models.

Acee
>
>-- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Acee Lindem (acee)]

Hi Jeff, Mahesh, 

See a couple inlines.

On 6/20/17, 10:16 AM, "Jeffrey Haas"  wrote:

>Mahesh,
>
>On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote:
>> > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas  wrote:
>> > Where we run into some issues are the cases highlighted: when the
>>sessions
>> > don't share common properties, how should the protocol pick what BFD
>>session
>> > to use?  
>> 
>> The issue that I hear most is the timer granularity. Is there something
>>else?
>
>Potentially mode (async vs. echo) and authentication.  However, I believe
>timer granularity is the biggest one.
>
>> > The current BFD yang model only permits a single IP single-hop session
>> > to be configured.  (Key is interface/dst-ip)  This means that if
>>different
>> > parameters *were* desired, the BFD model won't permit it today.
>>However,
>> > BFD sessions for many protocols tend not to be configured, but may
>>spring
>> > forth from protocol state, such as IGP adjacencies.  Thus, it's not
>> > "configured" - it's solely operational state.  However, the BFD yang
>>model
>> > doesn't really make good provision for that as an "on”.
>> 
>> The idea is that a BFD session is configured a priori and before a IGP
>>session is configured with the most aggressive timer. IGP sessions then
>>refer to the BGP session configured. If a IGP session is added that
>>requires a more aggressive timer, we would have to renegotiate the more
>>aggressive timer value.
>
>Consider a broadcast network segment such as Ethernet.
>Consider a few dozen routers on such a segment.
>
>Is it your expectation that an IGP would require each of those routers to
>be
>manually configured in the Yang module a priori?  That is, after all, much
>of the point of an IGP: automatic discovery.

I think the BFD model should support a wildcard for destination IP address
to avoid this problem.

>
>> > Where all endpoint state is known a priori, config state makes better
>>sense.
>> > 
>> > To pick the example of Juniper's configuration, if OSPF and eBGP were
>>using
>> > BFD, both can choose differing timers.  This represents two pieces of
>> > configuration state for the same endpoints.  Additionally, only one
>>BFD
>> > session is formed using the most aggressive timers.
>> 
>> That is what we are suggesting also.
>
>The distinguishing point is configuration vs. operational state.  The
>current model doesn't permit more than one set of parameters to be
>provisioned even if the implementation may choose to instantiate exactly
>one
>session.

This could be supported with extensions to the BFD model.

Thanks,
Acee 
>
>> > I partially point out the situation of multiple timers since there
>>have been
>> > prior list discussions on the situation where clients have different
>>timing
>> > requirements.  I don't think we handle this operationally in the BFD
>> > protocol in the cleanest fashion right now - the session will go to
>>Down
>> > when the aggressive timers fail and there's no clean way to
>>renegotiate to
>> > the less aggressive timers.
>> 
>> A BFD session would fail more likely because there is a real network
>>failure than because the timer was more aggressive than what IGP had
>>requested. 
>
>Please note that I raise this point mostly because of prior discussion.
>I'm
>well aware of the headaches this currently causes:
>
>Different protocols have different survivability requirements.  An IGP may
>very well want sub-second timers, potentially for repair behaviors.  BGP
>may
>want fast failover, but may be fine with second level granularity.  This
>is
>particularly true since the cost of too aggressively flapping BGP is of
>significantly greater impact to the network and the router.
>
>But moving to what *is* rather than what should be, if there are two
>different timing setups for the same endpoint: If you deprovision the more
>aggressive timer, the session should likely renegotiate to the less
>aggressive one rather than drop.
>
>-- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Jeffrey Haas]

Acee,

On Mon, Jun 19, 2017 at 10:10:43PM +, Acee Lindem (acee) wrote:
> I don’t really feel there is a strong requirement to support different
> timers values per protocol even though several implementations allow
> different protocol specific values to be configured (with varying
> behaviors). 
> 
> If there were such a requirement, I would think it would be better
> satisfied by extending the BFD model session key with an additional
> identifier, e.g., .

I suspect multi-instancing may be where this conversation goes.

> IMO, this would be
> preferable to allowing the details of BFD to permeate into all the other
> protocol models. This would require configuration of the instance rather
> than a boolean in the protocols.

My lingering concern is whether the client protocol may have preferences
about what session to use when such multi-instancing is permitted.
Minimally this would require some sort of Yang reference to the specific
instance.

As I'm noting in the other response, do we really expect BFD Yang model
users to pre-provision every single OSPF/ISIS adjacency in the config
stanza?  Likely, no.

What I tend to expect is a template being used for a service profile.  We
don't currently have such a thing.

> Acee 

-- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Jeffrey Haas]

Mahesh,

On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote:
> > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas  wrote:
> > Where we run into some issues are the cases highlighted: when the sessions
> > don't share common properties, how should the protocol pick what BFD session
> > to use?  
> 
> The issue that I hear most is the timer granularity. Is there something else?

Potentially mode (async vs. echo) and authentication.  However, I believe
timer granularity is the biggest one.

> > The current BFD yang model only permits a single IP single-hop session
> > to be configured.  (Key is interface/dst-ip)  This means that if different
> > parameters *were* desired, the BFD model won't permit it today.  However,
> > BFD sessions for many protocols tend not to be configured, but may spring
> > forth from protocol state, such as IGP adjacencies.  Thus, it's not
> > "configured" - it's solely operational state.  However, the BFD yang model
> > doesn't really make good provision for that as an "on”.
> 
> The idea is that a BFD session is configured a priori and before a IGP 
> session is configured with the most aggressive timer. IGP sessions then refer 
> to the BGP session configured. If a IGP session is added that requires a more 
> aggressive timer, we would have to renegotiate the more aggressive timer 
> value.

Consider a broadcast network segment such as Ethernet.
Consider a few dozen routers on such a segment.

Is it your expectation that an IGP would require each of those routers to be
manually configured in the Yang module a priori?  That is, after all, much
of the point of an IGP: automatic discovery.

> > Where all endpoint state is known a priori, config state makes better sense.
> > 
> > To pick the example of Juniper's configuration, if OSPF and eBGP were using
> > BFD, both can choose differing timers.  This represents two pieces of
> > configuration state for the same endpoints.  Additionally, only one BFD
> > session is formed using the most aggressive timers.
> 
> That is what we are suggesting also.

The distinguishing point is configuration vs. operational state.  The
current model doesn't permit more than one set of parameters to be
provisioned even if the implementation may choose to instantiate exactly one
session.

> > I partially point out the situation of multiple timers since there have been
> > prior list discussions on the situation where clients have different timing
> > requirements.  I don't think we handle this operationally in the BFD
> > protocol in the cleanest fashion right now - the session will go to Down
> > when the aggressive timers fail and there's no clean way to renegotiate to
> > the less aggressive timers.
> 
> A BFD session would fail more likely because there is a real network failure 
> than because the timer was more aggressive than what IGP had requested. 

Please note that I raise this point mostly because of prior discussion.  I'm
well aware of the headaches this currently causes:

Different protocols have different survivability requirements.  An IGP may
very well want sub-second timers, potentially for repair behaviors.  BGP may
want fast failover, but may be fine with second level granularity.  This is
particularly true since the cost of too aggressively flapping BGP is of
significantly greater impact to the network and the router.

But moving to what *is* rather than what should be, if there are two
different timing setups for the same endpoint: If you deprovision the more
aggressive timer, the session should likely renegotiate to the less
aggressive one rather than drop.

-- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf