Re: [OSPF] BFD re-charter complete

[Manav Bhatia <[e-mail]>]

Hi Acee,

You might also want to consider another draft submitted by Xu, Uma and
yours truly which advertises a reachable ipv4/6 address in ospf te tlvs.
That draft will be reqd by the sbfd to work.

Thx, Manav

--
Thumb typed by Manav
On Jun 10, 2014 10:20 PM, "Acee Lindem" <[e-mail]> wrote:

>  From: Ericsson <[e-mail]>
>  Date: Tuesday, June 10, 2014 9:34 AM
> To: Manav Bhatia <[e-mail]>, Jeffrey Haas <[e-mail]>, "
> [e-mail]" <[e-mail]>, OSPF - OSPF WG List <[e-mail]>
> Subject: Re: [OSPF] BFD re-charter complete
>
>   Hi Manav,
>
>   From: Manav Bhatia <[e-mail]>
> Date: Tuesday, June 10, 2014 7:40 AM
> To: Jeffrey Haas <[e-mail]>, "[e-mail]" <[e-mail]>,
> OSPF - OSPF WG List <[e-mail]>
> Subject: Re: [OSPF] BFD re-charter complete
>
>   Hi Jeff,
>
> What about the ospf/isis extn drafts for distributing the sbfd
> discriminators? I guess these would be owned by the respective IGP WGs. Is
> this correct?
>
>  Since the IGP drafts contain solely the TLV encoding and IGP flooding
> specifications, there is reason for them to be homed anywhere else.
>
>
>  All,
> I meant "no reason for them to be homed anywhere else".
> Thanks,
> Acee
>
>
>
>
>
>
>  Thanks,
> Acee
>
>
>
>    Cheers, Manav
>
> --
> Thumb typed by Manav
> On Jun 10, 2014 7:23 PM, "Jeffrey Haas" <[e-mail]> wrote:
>
>> Working Group,
>>
>> Our updated charter was approved by the IESG.  The S-BFD work is
>> officially
>> in scope now!
>>
>> Per our prior discussion, authors please submit the following documents as
>> draft-ietf-bfd-*:
>>
>> draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
>> draft-akiya-bfd-seamless-base (Milestone: March 2015)
>>
>> The following documents are known to be work of interest, but aren't quite
>> ready for adoption.  Please kick off additional discussions to drive that
>> work forward:
>>
>> draft-akiya-bfd-seamless-ip
>> draft-akiya-bfd-seamless-sr
>> draft-akiya-bfd-seamless-alert-discrim
>>
>> My recommendation is to drive the IP case first.
>>
>> -- Jeff
>>
>>
>>
>>
>>
>> ----- Forwarded message from The IESG <[e-mail]> -----
>>
>> Date: Thu, 05 Jun 2014 10:16:58 -0700
>> From: The IESG <[e-mail]>
>> To: IETF-Announce <[e-mail]>
>> Cc: bfd WG <[e-mail]>
>> Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
>>
>> The Bidirectional Forwarding Detection (bfd) working group in the Routing
>> Area of the IETF has been rechartered. For additional information please
>> contact the Area Directors or the WG Chairs.
>>
>> Bidirectional Forwarding Detection (bfd)
>> ------------------------------------------------
>> Current Status: Active WG
>>
>> Chairs:
>>   Nobo Akiya <[e-mail]>
>>   Jeffrey Haas <[e-mail]>
>>
>> Technical advisors:
>>   Dave Katz <[e-mail]>
>>   David Ward <[e-mail]>
>>
>> Assigned Area Director:
>>   Adrian Farrel <[e-mail]>
>>
>> Mailing list
>>   Address: [e-mail]
>>   To Subscribe: [e-mail]
>>   Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/
>>
>> Charter:
>>
>> The BFD Working Group is chartered to standardize and support the
>> bidirectional forwarding detection protocol (BFD) and its extensions.  A
>> core goal of the working group is to standardize BFD in the context of
>> IP routing, or protocols such as MPLS that are based on IP routing, in a
>> way that will encourage multiple, inter-operable vendor implementations.
>>
>> The Working Group will also provide advice and guidance on BFD to other
>> working groups or standards bodies as requested.
>>
>> BFD is a protocol intended to detect faults in the bidirectional path
>> between two forwarding engines, including physical interfaces,
>> subinterfaces, data link(s), and to the extent possible the forwarding
>> engines themselves, with potentially very low latency. It operates
>> independently of media, data protocols, and routing protocols. An
>> additional goal is to provide a single mechanism that can be used for
>> liveness detection over any media, at any protocol layer, with
>> a wide range of detection times and overhead, to avoid a proliferation
>> of different methods.
>>
>> Important characteristics of BFD include:
>>
>> - Simple, fixed-field encoding to facilitate implementations in
>>   hardware.
>>
>> - Independence of the data protocol being forwarded between two systems.
>>   BFD packets are carried as the payload of whatever encapsulating
>>   protocol is appropriate for the medium and network.
>>
>> - Path independence: BFD can provide failure detection on any kind of
>>   path between systems, including direct physical links, virtual
>>   circuits, tunnels, MPLS LSPs, multihop routed paths, and
>>   unidirectional links (so long as there is some return path, of
>>   course).
>>
>> - Ability to be bootstrapped by any other protocol that automatically
>>   forms peer, neighbor or adjacency relationships to seed BFD endpoint
>>   discovery.
>>
>> The working group is currently chartered to complete the following work
>> items:
>>
>> 1. Develop further MIB modules for BFD and submit them to the IESG for
>> publication as Proposed Standards.
>>
>> 2a. Provide a generic keying-based cryptographic authentication
>> mechanism for the BFD protocol developing the work of the KARP
>> working group.  This mechanism  will support authentication through
>> a key identifier for the BFD session's Security Association rather
>> than specifying new authentication extensions.
>>
>> 2b. Provide extensions to the BFD MIB in support of the generic keying-
>> based cryptographic authentication mechanism.
>>
>> 2c. Specify cryptographic authentication procedures for the BFD protocol
>> using HMAC-SHA-256 (possibly truncated to a smaller integrity check
>> value but not beyond commonly accepted lengths to ensure security) using
>> the generic keying-based cryptographic authentication mechanism.
>>
>> 3. Provide an extension to the BFD core protocol in support of point-to-
>> multipoint links and networks.
>>
>> 4. Provide an informational document to recommend standardized timers
>> and timer operations for BFD when used in different applications.
>>
>> 5. Define a mechanism to perform single-ended path (i.e. continuity)
>> verification based on the BFD specification.  Allow such a mechanism to
>> work both proactively and on-demand, without prominent initial delay.
>> Allow the mechanism to maintain multiple sessions to a target entity and
>> between the same pair of network entities. In doing this work, the WG
>> will work closely with at least the following other WGs: ISIS, OSPF,
>> SPRING.
>>
>> The working group will maintain a relationship with the MPLS working
>> group.
>>
>> Milestones:
>>   Done     - Submit the base protocol specification to the IESG to be
>> considered as a Proposed Standard
>>   Done     - Submit BFD encapsulation and usage profile for single-hop
>> IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
>> Standard
>>   Done     - Submit BFD encapsulation and usage profile for MPLS LSPs to
>> the IESG to be considered as a Proposed Standard
>>   Done     - Submit BFD encapsulation and usage profile for multi-hop
>> IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
>> Standard
>>   Done     - Submit the BFD MIB to the IESG to be considered as a
>> Proposed Standard
>>   Done     - Submit the BFD over LAG mechanism to the IESG to be
>> considered as a Proposed Standard
>>   Jun 2014 - Submit the the document on BFD point-to-multipoint support
>> to the IESG to be considered as a Proposed Standard
>>   Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
>> considered as a Proposed Standard
>>   Jan 2015 - Submit the generic keying based cryptographic authentication
>> mechanism to the IESG to be considered as a Proposed Standard
>>   Jan 2015 - Submit a BFD MIB extension in support of the generic keying
>> document to the IESG to be considered as a Proposed Standard
>>   Jan 2015 - Submit the cryptographic authentication procedures for BFD
>> to the IESG to be considered as a Proposed Standard
>>   Jan 2015 - Submit the BFD Common Intervals document to the IESG to be
>> considered as an Informational RFC
>>
>>
>> ----- End forwarded message -----
>>
>>