Thanks for the review, Elwyn. Ice, is a new version upcoming? (The telechat is in a moment… just wanted to check that we’ve not forgotten anything, it is of course fine to collect various changes to a draft revision that you’ll post after the call as well.)
Jari On 14 Nov 2014, at 20:07, Elwyn Davies <elw...@dial.pipex.com> wrote: > Hi, Ijsbrand/Ice, > > Thanks for the response.It seems there isn't much that can be done about the > error handling. I shall escalate this problem as a generic check that we > need to make sure that unused extension systems defined in base protocols > have adequate error handling/reporting for when the extensibility gets used. > > Are you intending to generate a new version before the IESG review? I see > this is now scheduled for 30 November, and it would be useful to know whether > there will be a new version to check out for the IESG review report. > > Cheers, > Elwyn > > On 04/11/14 22:03, IJsbrand Wijnands wrote: >> Hi Elwyn, >> >>> Summary: Almost ready. There are a couple of clarifications around >>> how IPv4 and IPv6 trees can or cannot be merged on a single MP-LSP >>> that would be advantageous. Also the error handling in the parent >>> RFCs (6388, 6826) is a bit sketchy resulting in messy handling if >>> an LSR that does not support the wildcard encoding is accidentally >>> sent the TLVs from this draft. I am not sure if this can be >>> cleaned up (and maybe there is no thought to be a problem - I am >>> not sufficiently expert in LDP signalling). >> >> I don’t think that is a problem, the wildcard encoding i.e. ‘all >> zero’s’, is an invalid value in implementation that don’t support it. >> So these routers would just drop the label mapping when this >> happens. >> >>> Minor issues: IPv4 and IPv6 Multicast: I think it would be useful >>> to add a short discussion of the fact that there are both IPv4 and >>> IPv6 multicast trees. Presumably an MP-LSP can only carry one or >>> the other at a time, but I am unclear about whether this is the >>> case. Also a note in s3.1 that it is either the IPv4 or IPv6 >>> address fields that are relevant and they are all zeroes in either >>> case would clarify the usage further. >> >> We are not changing anything about how an LSP is used, either for >> IPv4 or IPv6. We’re only allowing *all* sources within a IPv4 or IPv6 >> group to be forwarded down the LSP. I don’t think we should add >> anything here since we are not changing the default behaviour. > > I understand that. To a novice reading the document it would be useful to > add a sentence after the first three paras of s3.2, something like: > The wildcard scheme allows multicast traffic for multiple sources or > multiple trees for either IPv4 or IPv6 traffic, but not both, to > share a single MP-LSP according to the type of TLV used. >> >>> RFC 5918 Typed Wildcard: Is there anything special that has to be >>> done if the Typed Wildcard is used? >> >> No, a typed wildcard does not encode any mLDP Source or Group address >> fields, so this draft does not apply. >> > OK > >>> >>> s3.3: Is it possible to specify the error behaviour more >>> concretely (i.e., what might happen) in case an unadapted Ingress >>> LSR gets a wildcard TLV? It appears that RFC 6826 is rather >>> underspecified as regards error handling - but I am not an expert >>> on this area - it appears that the MP-LSP would get set up but to >>> no good purpose which seems inappropriate. Could an error status >>> not be returned? >> >> For the Opaque in-band TLV's that mLDP FEC’s carry there is no error >> signalling defined in the base RFC. If you receive an opaque type for >> an in-band TLV and you don’t support it, you’ll just drop the label >> mapping. I agree this would have been useful to add a LDP capability >> in the base RPF 6826. Since this draft is just a minor update to the >> functionality as defined in 6826, it does make sense to do it now. >> > > Pity. Do I understand correctly that the egress LSR will be none the wiser > that its request has been effectively silently ignored? There doesn't seem > to be much that can be done at this stage. > > *** NOT SPECIFIC TO THIS DRAFT: There is a generic point here that when > extensible capabilities are put in place in protocols but not actually used > in the base protocol, we need to be sure that adequate error signalling is > put in place so that a later (mis)use of the extensible capabilities can be > detected and reported appropriately. This is the second instance I have seen > in the recent past where there was inadequate error reporting capability to > handle an extension scheme. >>> >>> >>> Nits/editorial comments: s2, Definition of 'in-band signalling': >>> Should also allow for (S,*) - and possibly (*,*), I believe. >> >> Yes, I’ll change this. >> >>> >>> s3.4: s/PIM ASM/PIM-ASM/ >> >> Ok, >> >> Thanks for your review, >> >> Ice. >> >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
