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" <[email protected]> wrote: > From: Ericsson <[email protected]> > Date: Tuesday, June 10, 2014 9:34 AM > To: Manav Bhatia <[email protected]>, Jeffrey Haas <[email protected]>, " > [email protected]" <[email protected]>, OSPF - OSPF WG List <[email protected]> > Subject: Re: [OSPF] BFD re-charter complete > > Hi Manav, > > From: Manav Bhatia <[email protected]> > Date: Tuesday, June 10, 2014 7:40 AM > To: Jeffrey Haas <[email protected]>, "[email protected]" <[email protected]>, > OSPF - OSPF WG List <[email protected]> > 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" <[email protected]> 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 <[email protected]> ----- >> >> Date: Thu, 05 Jun 2014 10:16:58 -0700 >> From: The IESG <[email protected]> >> To: IETF-Announce <[email protected]> >> Cc: bfd WG <[email protected]> >> 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 <[email protected]> >> Jeffrey Haas <[email protected]> >> >> Technical advisors: >> Dave Katz <[email protected]> >> David Ward <[email protected]> >> >> Assigned Area Director: >> Adrian Farrel <[email protected]> >> >> Mailing list >> Address: [email protected] >> To Subscribe: [email protected] >> 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 ----- >> >>
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
