Hello Greg, Thanks for your comments. Please see my reply inline tagged[ SPK].
Thanks Santosh P K On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <[email protected]> wrote: > Dear Authors, WG chairs, et. al, > please kindly consider my comments to the latest version of the draft as > part of WGLC: > > - Very general > - I suggest to add note clarifying that all terms that include > "connectivity" in the document are being used as alternative to > "continuity", i.e. existence of a path between the sender and the > receiver, > and should not be interpreted as "connectivity verification in terms of > transport network". > - Introduction > - I find that characterization of BFD and unidirectional continuity > verification as "natural fit" bit of stretching. Perhaps "capable of > supporting this use case" is acceptable; > > [SPK] Will take care. > > - Goals > - the last statement of non-goal seems little unclear. In fact, if > there's only one tail, the BFD for multipoint network does verify > connectivity, though unidirectional, between the head and the tail. I > think > that the intention is to stress that p2p bi-directional connectivity > verification is not supported by this document. > > [SPK] It only says that this document does not support verification of unicast path between head and tail. I can clarify a bit on this. Please let me know if you have a suggestion for this. > > - Section 4.7 > - the last paragraph notes that the discriminator value MUST NOT be > changed. Since Your Discriminator MUST be set to 0 this refers to My > Discriminator only. I think that explicit reference will make the > statement > more clear. Thus suggest s/the discriminator values/the My Discriminator > value/ > > [SPK] Will take care of this. > > - Section 4.8 > - I believe that requiring use of IP/UDP encapsulation for BFD in > multipoint networks over MPSL LSP is too restrictive. I suggest changing > text as following: > > OLD: > > For multipoint LSP, MultipointTail MUST use destination UDP port "3784" and > IP "127.0.0.0/8" range. > > > NEW > > If IP/UDP encapsulation used by MultipointHead for multipoint LSP, > MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port > "3784" and IP "127.0.0.0/8" range. > > Use of other types of encapsulation for multipoint LSP is outside the scope > of this document. > > [SPK] Thanks. I think this make sense for non MPLS tunnels. > > - Section 4.10 > - I cannot say what bfd.DetectMult packet is. It has not been defined > in RFC 5880, nor in this document. What is the scenario described in the > second paragraph? Is it when MultipointHead reduces Desired Min TX Interval > thus making defect detection more aggressive? > - > > [SPK] This section talks about how to handle Poll sequence. In case of Multipoint head we cant afford to send POLL and expect all tail to reply with F bit set. Keeping track and building state at headend will be costly. > > - Section 7 > - I think it should be plural in the first paragraph, i.e. > s/MultipointTail session/MultipointTail sessions/ > - I think that we can add another consideration to improve, strengthen > security of BFD for multipoint network by suggesting that MultipointTail > sessions created only for known combination of MultipointHead and My > Discriminator. Such information MAY be learned from out-of-band and > mechanisms are outside the scope of this document. > > > Regards, > > Greg > > > > On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <[email protected]> wrote: > >> Working Group, >> >> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 >> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 >> >> >> The BFD Multipoint documents have been stable for some time. Prior >> discussion at meetings has suggested we have an implementation for the >> main >> protocol component. Also per prior discussions, we split the active-tail >> component of the original multipoint document to permit implementors to >> not >> have to worry about implementing active-tail procedures if they weren't >> interested in that feature. >> >> We are starting an extended last call on these documents. The WGLC will >> conclude on July 14. This provides ample time for list discussion. If >> necessary, the IETF-99 meeting may provide for opportunities to close any >> contentious technical points. (BFD is not currently scheduled to meet.) >> >> One item I would like to kick off is the document status of the >> active-tail >> mechanism. At this time, no one has implemented it that I am aware of. >> Discussion with our AD suggests that publishing the document with >> Experimental status may be reasonable to preserve the work that went into >> the proposal. >> >> -- Jeff >> >> >
