Marc, Thanks for your valuable comments :). Please see my inline comments tagged [SPK].
Thanks Santosh P K > -----Original Message----- > From: Marc Binderberger [mailto:[email protected]] > Sent: Monday, December 14, 2015 1:33 PM > To: Alvaro Retana <[email protected]>; Santosh P K > <[email protected]>; [email protected] > Cc: [email protected]; [email protected] > Subject: Re: AD Review of draft-ietf-bfd-seamless-base > > Hello Santosh, authors, Alvaro and list members, > > for the quoted section 3 of draft-ietf-bfd-seamless-base it gets even > "worse", as it says for the example in that section: > > The IS-IS with SystemID xxx (node A) allocates an S-BFD discriminator > 123, and advertises the S-BFD discriminator 123 in an IS-IS TLV. The > IS-IS with SystemID yyy (node D) allocates an S-BFD discriminator > 456, and advertises the S-BFD discriminator 456 in an IS-IS TLV. > > > So it puts the IGP (IS-IS in this case) into an authoritative role. The IS-IS > teams > respond with "whoa, wait, I'm just the messenger" :-) [SPK] IGP is indeed just a messenger at least in this contest. How could we reword this to ensure that it does not look like that. You have any suggestion on this? > > Section 3 also says > > An S-BFD module on each network node allocates one or more S-BFD > discriminators for local entities, and creates a reflector BFD > session. > > A bit if a contradiction - who is allocating now, S-BFD or the IGP? > I would think it is the S-BFD module that allocates and orchestrates. It uses > an > IGP or other means to transport discriminators to S-BFD modules on other > nodes. > > The reason is that S-BFD creates the BFD reflector, so it should know what > this reflector is for (maybe pure IPv6, or used for specific QoS etc.). [SPK] Yes you are right. SBFD module will allocates the discriminator. I will correct this in document. > > > There is another aspect: the protocols (OSPF, IS-IS, L2TP) plan to transport > a list of discriminators. Okay ... but how is the receiver S-BFD module > making sense out of this list? Would have expected something like (type, > discriminator). The protocols don't need to understand the details, only that > the API transports one or more of these tuples in/out of the protocol > module. > S-BFD would know/define what a particular type means. > > Just asking before we send OSPF, IS-IS, L2TP into the wrong direction :-) [SPK] This is implementation specific right? Do we need this to be captured in document? > > > Regards, Marc > > > > On Tue, 8 Dec 2015 16:47:53 +0000, Alvaro Retana (aretana) wrote: > > Santosh: > > > > Hi! > > > > There are 2 more things (Major) that I need you to address. Sorry, I > > almost forgot. > > > > (A) Please take a look at the SecDir comments here [1]. > > > > [1] > > https://mailarchive.ietf.org/arch/msg/secdir/o7CSlWeRPh4- > BZBTI_eDyoBM7ak > > > > > > > > (B) > > > > During the IESG review of draft-ietf-isis-sbfd-discriminator the question > > came up about how the mapping of S-BFD discriminators (advertised by IS- > IS > > in that draft, but there are also similar OSPF and L2TP drafts) to > > specific applications/entities is to be done. This conversation ended up > > in me placing a DISCUSS on that document [2]. > > > > The problem is that draft-ietf-isis-sbfd-discriminator (and the OSPF and > > L2TP drafts) declare the mapping out of scope. *AND* This document > > (draft-ietf-bfd-seamless-base) says this in Section 3. (Seamless BFD > > Overview): > > > > An S-BFD module on each network node allocates one or more S-BFD > > discriminators for local entities, and creates a reflector BFD > > session. Allocated S-BFD discriminators may be advertised by > > applications (e.g., OSPF/IS-IS). Required result is that > > applications, on other network nodes, possess the knowledge of the > > mapping from remote entities to S-BFD discriminators. The reflector > > BFD session is to, upon receiving an S-BFD control packet targeted to > > one of local S-BFD discriminator values, transmit a response S-BFD > > control packet back to the initiator. > > > > This text reads to me that S-BFD is expecting ("Required result") the > > mapping to be somehow provided by the "applications (e.g., OSPF/IS-IS)". > > Note that one possible interpretation is not for OSPF/IS-IS to "know" > > anything about S-BFD discriminators/entities, but to transport that > > information (similar to transporting discriminators). I can see at least > > one relevant use case (in draft-ietf-bfd-seamless-use-case) that seems to > > require the ability to distinguish and map: Section 3.8. (Multiple BFD > > Sessions to Same Target). > > > > The point to address is this: what is the expectation (from the S-BFD > > point of view) with respect to the mapping? > > > > Answering may require a WG-wide discussion. Depending on the answer, > > there may be obvious effects (and work needed) in the isis, ospf and > > l2tpext WGs, so please (with the help of the chairs) work with them. > > > > > > Thanks! > > > > Alvaro. > > > > [2] > > https://datatracker.ietf.org/doc/draft-ietf-isis-sbfd-discriminator/ballot/ > >
