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. > 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. > > 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. > > > 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
