[snippety-snack]
> >>3.2.2. Node Address P2MP Responder Identifier Sub-TLVs
> >>
> >> The address in this Sub-TLV SHOULD be of any transit, branch, bud or
> >> egress node for that P2MP LSP.
> >>
> >>Is the use of SHOULD correct here (instead of a MUST)? Are there any choices
> >>left if the SHOULD is violated?
> >>
> >The MAY clause can be added.
> >
> I think you've missed my point. If the list of node types is complete,
> then there is no need to use a SHOULD (because it is a MUST and that
> MUST doesn't need to be stated). Are there other types of nodes?
Oh, my! Yes, I missed your point.
Yes, indeed, there are other types of nodes.
If you take just a small step back you'll see that there are more nodes in the
Internet than are present as participating nodes in just one P2MP LSP :-)
There might be more than three use cases, but, for example:
- ingress node (self-pinging leads to blindness?)
- node that you want to check is really not on the path
- node you know is not on the path because you want to check
everyone else is functioning correctly (i.e., not responding)
So perhaps we need to add the MAY clause.
> >>4.2.1.1. Responses from Transit and Branch Nodes
> >>
> >> The presence of a Downstream Detailed Mapping TLV will influence the
> >> choice of Return Code. As per [DDMT], the Return Code in the echo
> >> response header MAY be set to value TBD ('See DDM TLV for Return Code
> >>
> >>Am I correct that the value TBD is specified in [DDMT]?
> >>
> >>
> >You are correct as in the very next line that you cut off with your question.
> >
> >
> I think it would be a good idea to insert a note for RFC Editor here
> asking to fix TBD when [DDMT] is published. That wasn't very clear to me.
> [...]
I think the RFC Editor searches for "TBD". The two documents are lock-stepped in
the process and so on. But we can ask the AD to add an RFC Editor note.
Thanks,
Adrian
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
