Hi Santosh, many thanks for your thoughtful consideration of my comments. Please find my answers and couple more notes in-line and tagged GIM>>.
Regards, Greg On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <[email protected]> wrote: > 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. > GIM>> Thanks > >> - 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. > GIM>> I'd suggest to use unicast in place of point-to-point. Using my earlier example, in case when there's only one tail multipoint becomes point-to-point. > > >> >> - 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. > GIM>> Thanks. > >> - 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. > GIM>> Thanks. As I've looked at the text, I've realized that it misses IPv6 case. Please consider the following as my new proposed change (not sure but I think that quote marks are not required): NEW If IP/UDP encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range for IPv6. Use of other types of encapsulation for multipoint LSP is outside the scope of this document. >> - 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. > > GIM>> Perhaps I wasn't clear in my question. It was to the opening of this sentence: The MultipointHead MUST send bfd.DetectMult packets with P bit set at the old transmit interval before using the higher value in order to avoid false detection timeouts at the tails. I couldn't find reference to "bfd.DetectMult packet" in any document related to BFD. >> - 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 >>> >>> >> >
