The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Two comments as part of the last call:

1. The spec should clarify which HOP object is used when. Suggest adding
at the end of 5.1:

"IF_ID RSVP_HOP object MUST be used on links where there is
not a one-to-one association of a control channel to a data channel
[RFC3471]. RSVP_HOP object defined in [RFC2205] SHOULD be used otherwise."


2. Section 18.1.1

"There are two approaches to dealing with re-merge case.  In the
   first, the node detecting the re-merge case, i.e., the re-merge node,
   allows the re-merge case to persist but data from all but one
   incoming interface is dropped at the re-merge node.  In the second,
   the re-merge node initiates the removal of the re-merge branch(es)
   via signaling.  Which approach is used is a matter of local policy.
   A node MUST support both approaches and MUST allow user configuration
   of which approach is to be used."

I don't think it is necessary for a node to support both approaches. What
is required is that a node that detects remerge MUST be able to support at
least one of the approaches.

Further for the second approach to work a node MUST be able to receive
and process the PathError with "P2MP Remerge Detected" value. This is
already implied by the text that follows in this section.

With this in mind I propose changing the above paragraph to:

"There are two approaches to dealing with re-merge case.  In the
   first, the node detecting the re-merge case, i.e., the re-merge node,
   allows the re-merge case to persist but data from all but one
   incoming interface is dropped at the re-merge node.  In the second,
   the re-merge node initiates the removal of the re-merge branch(es)
   via signaling. A node that detects the re-merge case MUST support
   at least one of the approaches. If a node that detects the re-merge
   case supports both the approaches it MUST allow user configuration of
   which approach is to be used."


rahul

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls