Hi Brian, Thanks for the ack.
Yah, we will ensure to get the references section updated. So far, no other changes. Thanks again for your review and support. Cheers, Rajiv > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Monday, July 27, 2009 5:20 PM > To: Rajiv Asati (rajiva) > Cc: [email protected]; General Area Review Team; > [email protected]; Adrian Farrel > Subject: Re: Gen-ART LC review of draft-ietf-mpls-ldp-end-of-lib-03.txt > > Rajiv, > > Thanks. I agree that this covers it. There is a remaining editorial > issue: the draft actually refers to [LDPCap], which is the draft > of RFC5561, so that needs to be fixed. If there are no other changes > I'm sure that can be done by the RFC Editor as a routine action. > > Brian > > On 2009-07-28 04:22, Rajiv Asati (rajiva) wrote: > > Hi Brian, > > > > Thanks for the review. We believe that your comment is already addressed. > > > > What you are commenting is that if R1 (in the below topology) > > sends "Unrecog Notif" capability to R2 during session > > initialization, which has no clue about this capability, then > > the issue of R2 not understanding the capability would creep up > > during session initialization. > > > > R1---------R2 > > > > If so, then you are right about this issue. And we believe that > > this issue is already addressed by the LDP capability draft > > [RFC5561] section 6, as you suggested: > > > > <snip> > > to 0 otherwise. If a speaker receives a message containng unsupported > > capability, it responds according to U-bit setting in the TLV. If U- > > bit is 1, then speaker MUST silently ignore the Capability Parameter > > and allow the session to be established. However, if U-bit is 0, then > > speaker SHOULD send a Notification message to the peer before > > terminating the session. The Status Code in the Status TLV of the > > </snip> > > > > > > Thankfully, RFC5561 is already a normative reference in our document, so, we > don't think that our document needs any changing. Please let us know if you > think otherwise. Would be glad to accommodate your suggestion. > > > > Thanks. > > > > Cheers, > > Rajiv > > > > PS: For everyone's reference, here is Brian's comment: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> 3. Unrecognized Notification Capability > >> > >> An LDP speaker MAY include a Capability Parameter [LDPCap] in the > >> Initialization message to inform a peer that it ignores Notification > >> Messages that carry a Status TLV with a non-fatal Status Code unknown > >> to it. > > > > You use this to avoid the problem of a speaker not understanding "End-of- > LIB". > > But what happens if the recipient does not understand "Unrecog Notif"? > Doesn't > > that create a similar problem during initialization? > > > > Actually the general design principle of silent discard should apply here, > > to both these indications. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:[email protected]] > >> Sent: Sunday, July 26, 2009 5:15 PM > >> To: [email protected]; General Area Review Team > >> Cc: [email protected]; Adrian Farrel > >> Subject: Gen-ART LC review of draft-ietf-mpls-ldp-end-of-lib-03.txt > >> > >> > >> > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
