The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi Adrian,

Thanks for the detailed comments. I am still looking at all your comments
and will respond in a few days..

rahul

On Fri, 19 May 2006, Adrian Farrel wrote:

> Hi,
>
> Thanks to the editors. Good job.
>
> Here are some comments...
>
> Adrian
>
> ==
> Title
> Here you say "Point to Multipoint", but in the rest of the document it is
> hyphenated.
> ==
> Abstract
> s/setup/set up/
> (setup is a noun not a verb)
> ==
> Abstract
> Looks like you want a paragraph break before...
> "There can be various applications..."
> ==
> Section 3.
> Acronyms must be spelt out the first time they are encountered.
> The Abstract (regrettably) is stand-alone and doesn't count, so the
> Introduction has to do it all again :-(
> Anyway, P2P and S2L are new.
> ==
> Section 3 para 3
>    One Path message may signal one
>    or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP
>    LSP can be signaled using one Path message or split across multiple
>    Path messages.
> The conjunction of these two sentences implies that a single Path message
> may also contain the S2L sub-LSPs from different P2MP LSPs. I don't believe
> this is the case, and we should correct this text accordingly. For example:
>    One Path message may signal one or multiple S2L sub-LSPs
>    for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP
>    LSP can be signaled using one Path message or split across multiple
>    Path messages.
> ==
> Section 3 para 4
> s/application specific/application-specific/
> ==
> Section 4 para 1
>    A branch node is an LSR that is capable of replicating the
>    incoming data on two or more outgoing interfaces.
> Technically, it only replicates it on one or more outgoing interfaces,
> because the first interface is not a replication.
> ==
> Section 4.1 para 1
>    The specific aspect related to a P2MP TE LSP is the action required
>    at a branch node, where data replication occurs. Incoming MPLS
>    labeled data is appropriately replicated to several outgoing
>    interfaces which may have different labels.
> Not sure if this is trying to say something more, or is just poorly worded.
> How about...
>    The defining feature of a P2MP TE LSP is the action required
>    at branch nodes where data replication occurs. Incoming MPLS
>    labeled data is appropriately replicated to several outgoing
>    interfaces which may use different labels for the data.
> ==
> Section 4.1 para 2
>    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
>    identified by a P2MP SESSION object. This object contains the
>    identifier of the P2MP Session which includes the P2MP ID, a tunnel
>    ID and an extended tunnel ID.
> Need to turn this paragraph around a bit.
>    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
>    identified the P2MP ID, a tunnel ID, and an extended tunnel ID. These
> objects
>    are carried in RSVP-TE in a P2MP SESSION object.
> ==
> Section 4.1 para 3
>    The fields of a P2MP SESSION object are identical to those of the
>    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
>    Address field is replaced by the P2MP Identifier (P2MP ID) field.
> The comparison is not quite so simple in the IPv6 case because the 16 byte
> IPv6 tunnel endpoint address is replaced by a 4 byte P2MP ID. We should
> bring this out in this paragraph as follows.
>    The fields of a P2MP SESSION object are identical to those of the
>    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
>    Address field (IPv4 or IPv6) is replaced by the 4-byte P2MP Identifier
>    (P2MP ID) field.
> ==
> Section 4.1
> Add a forwards reference at the end of the section as follows.
>    The new P2MP SESSION object is defined in section 19.1.
> ==
> Section 4.2
> s/20.2/19.2/
> ==
> Section 4.3 para 3
> s/subgroup/sub-group/
> Please do global search and replace in the document
> ==
> Section 4.3 para 3
> s/an egress and semantic/an egress, and semantic/
> ==
> Section 4.4.1 para 1
> s/20.3/19.3/
> ==
> Section 4.4.1 para 2
> s/20.5/19.5/
> s/20.6/19.6
> ==
> Section 4.4.1 and onwards
> The S2L_SUB_LSP object is consistently referred to in angle brackets, but no
> other object is given this treatment. Please remove the brackets everywhere
> except in BNF.
> ==
> Section 4.4.1
> It seems to me that the S2L_SUB_LSP object contains a leaf identifier and an
> SERO.
> The SERO provides the path from the last branch to the leaf.
> This means that it is not an S2L_SUB_LSP object at all, but really a
> S2L_SUB_LSP object. But that sounds clumsy.
> Can we call this a LEAF object?
> We would also rename the descriptor lists in section 5.1, 6.1, 7.1, and
> 11.1.
> We could change the names of the IPv4/IPv6 S2L Sub-LSP destination address,
> but that isn't necessary.
> ==
> Section 4.4.2 para 1
> s/setup/set up/
> ==
> Section 4.5 para 1
>    When a Path message signals a single S2L sub-LSP (that is, the Path
>    message is only targeting a single leaf in the P2MP tree), the
>    EXPLICIT_ROUTE object encodes the path from the ingress LSR to the
>    egress LSR.
> Strike the words "from the ingress LSR" as this situation may also occur
> within the network (for example, downstream of a branch node, or just
> anywhere if the original Path message only included one S2L sub-LSP).
> ==
> Section 4.5 para 2
>    When a Path message signals multiple S2L sub-LSPs the path of the
>    first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded
>    in the ERO.
> As above, strike "from the ingress LSR"
> ==
> Section 4.5 para 3
> s/(as defined in [RFC3209])/(as defined in [RFC3209] and [RFC3473])/
> ==
> Section 4.5 para 3
>    Each subsequent S2L sub-LSP
>    is represented by tuples of the form < [<P2MP
>    SECONDARY_EXPLICIT_ROUTE>] <S2L_SUB_LSP> >.
> Should read...
>    Each subsequent S2L sub-LSP
>    is represented by tuples of the form <  <S2L_SUB_LSP>,
>    [<P2MP SECONDARY_EXPLICIT_ROUTE>] >.
> ...since this is the order used in the encoding.
> ==
> Section 4.5 para 3
>    An SERO for a particular
>    S2L sub-LSP includes only the path from a certain branch LSR to the
>    egress LSR if the path to that branch LSR can be derived from the ERO
>    or other SEROs.
> Strike "certain" as this applies to any branch LSR in any network.
> ==
> Section 4.5 para 3
> s/20/19/
> ==
> Section 4.5 para 6
> s/Following/The following/
> Also near the top of page 10.
> ==
> Section 4.5
> s/exercise to the reader./exercise for the reader./
> ==
> Section 4.5 page 10
> s/A LSR/An LSR/
> s/a S2L/an S2L/
> s/a SERO/an SERO/
> Probably worth checking the whole document.
> ==
> Section 5.1
> layout of <S2L sub-LSP descriptor> is messed up
> ==
> Section 5.1
>    A SERO corresponds to the following <S2L_SUB_LSP>
>    object.
> s/A/An/
> Oh no it doesn't! Say...
>    An SERO corresponds to the preceding <S2L_SUB_LSP>
>    object.
> ==
> Section 5.1
>    The RRO in the sender descriptor contains the hops traversed by the
>    Path message and applies to all the S2L sub-LSPs signaled in the Path
>    message.
> That is rather an MPLS-centric view of the world. Better to say...
>    The RRO in the sender descriptor contains the upstream hops traversed
>    by the LSP up to this point and applies to all the S2L sub-LSPs signaled
>    in the Path message.
> ==
> Section 5.2 para 1
> s/ingress-LSR/ingress LSR/
> s/egress-LSR/egress LSR/
> s/that is the destination/that is a destination/
> ==
> Section 5.2 para 1
>    Another S2L sub-LSP belonging to the same instance of this
>    S2L sub-LSP (i.e.  the same P2MP LSP) shares resources with this S2L
>    sub-LSP.
> In previous versions of the draft we had "can share" in place of "shares",
> and this was with good reason. It is perfectly acceptable for replication to
> take place at an upstream node and for two copies of the data to flow on the
> same link before being fanned out down stream. This might happen in an
> optical network where the split node is not capable of the appropriate
> lambda conversions, but might also happen in a packet network where the
> downstream node cannot perform sufficient replication in a timely manner (or
> at all) and so some of the replication must be done upstream regardless of
> the 'waste' of resources in the network.
> Since we are in 2119-land (these are protocol procedures) please replace
> "shares" with "MAY share".
> However (!) note that in 5.2.1 para 4 we have "SHOULD".
> I can accept "SHOULD" in this paragraph, too.
> ==
> Section 5.2 para 1
> s/identified using the <S2L_SUB_LSP> object/identified using the
> <S2L_SUB_LSP> objects/
> ==
> Section 5.2 para 2
> s/20/19/
> ==
> Section 5.2.1 para 1
> You have changed your notation for tuples
> ==
> Section 5.2.1 para 3
>    An ingress LSR may use multiple Path messages for signaling a P2MP
>    LSP.
> s/may/MAY/
> ==
> Section 5.2.1 para 3
>    This implies that each Path message that is used
>    to signal a P2MP LSP is signaled using the same signaling attributes
>    with the exception of the S2L sub-LSP information and Sub-Group
>    identifiers.
> s/information/descriptor/
> s/identifiers/identifier/
> ==
> Section 5.2.1 para 5
>    In this case the message can be decomposed
>    into multiple Path messages such that each of the messages carry a
>    subset of the X2L sub-tree carried by the incoming message.
> s/carry/carries/
> ==
> Section 5.2.1 para 6
>    In order
>    to disambiguate these Path messages a <Sub-Group Originator ID, sub-
>    Group ID> tuple is introduced (also referred to as the Sub-Group
>    field) and encoded in the SENDER_TEMPLATE object.
> s/field/fields/
> ==
> Section 5.2.1 para 6
>    This is either the ingress
>    LSR or a LSR which re-originates the Path message with its own Sub-
>    Group Originator ID.
> This sentence doesn't add anything. Strike it.
> ==
> Section 5.2.1 para 6
>    The <Sub-Group Originator ID, sub-Group ID> tuple is globally unique.
> I'm not sure what this means.
> The same LSR can use the same sub-Group ID on different LSPs since the LSPs
> are distinguished by session/sender template.
> Further, there is some conflict with the sentences immediately afterwards...
>    The sub-Group ID space is specific to the Sub-Group Originator ID.
>    Therefore the combination <Sub-Group Originator ID, sub-Group ID> is
>    network-wide unique.
> Since no conclusion appears to be drawn from this uniqueness, I would say
> that the sub-Group ID is unique within the context of a P2MP LSP and that
> the sub-Group Originator ID is network-wide unique.
> ==
> Section 5.2.1 para 6
>    Also, a router that changes the Sub-Group
>    originator ID of an incoming Path message MUST use the same value of
>    the Sub-Group Originator ID for all outgoing Path messages, for a
>    particular P2MP LSP, and SHOULD not vary it during the life of the
>    P2MP LSP.
> This may be confusing in the light of the fact (a few lines earlier) that...
>    The Sub-Group Originator ID MUST be set to the TE Router ID of
>    the LSR that originates the Path message.
> Certainly the "MUST"s are complementary, but what is with the "SHOULD"?
> ==
> Section 5.2.2 para 1
>    The S2L sub-LSP descriptor list allows the signaling of one or more
>    S2L sub-LSPs in one Path message. It is possible to signal multiple
>    <S2L_SUB_LSP> object and ERO/SERO combinations in a single Path
>    message. Note that these two objects differentiate a S2L sub-LSP.
> The first two sentence are largely duplicates.
> The third sentence says two objects, three have been mentioned.
> How about...
>    The S2L sub-LSP descriptor list allows the signaling of one or more
>    S2L sub-LSPs in one Path message. Each S2L sub-LSP descriptor
>    describes a single S2L sub-LSP.
> ==
> Section 5.2.2 3rd bullet
>        - If the first hop of the SERO is not a local address of the LSR
>          the S2L sub-LSP descriptor MUST be included in the Path message
>          sent to LSR that is the next hop to reach the first hop in the
>          SERO. This next hop is determined by using the ERO or other
>          SEROs that encode the path to the SERO's first hop.
> s/sent to LSR/sent to the LSR/
> ==
> Section 5.2.2
>    Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
>    descriptors on each downstream link. A S2L sub-LSP descriptor list
>    that is propagated on a downstream link MUST only contain those S2L
>    sub-LSPs that are routed using that link. This processing MAY result
>    in a subsequent S2L sub-LSP in an incoming Path message to become the
>    first S2L sub-LSP in an outgoing Path message.
> I'm not sure if this is what I wrote, but anyway, it is wrong!
> Path messages are not propagated on downstream links, but are sent to the
> next hop towards the egress. This finesse of words is important when
> out-of-channel signaling is considered. So reword as follows...
>    Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
>    descriptors to each next downstream hop. An S2L sub-LSP descriptor list
>    that is propagated to a downstream hop MUST only contain those S2L
>    sub-LSPs that are routed using that hop. This processing MAY result
>    in a subsequent S2L sub-LSP in an incoming Path message to become the
>    first S2L sub-LSP in an outgoing Path message.
> ==
> Section 5.2.2
>    Note that if one or more SEROs contain loose hops, expansion of such
>    loose hops MAY result in overflowing the Path message size. Section
>    5.2.3 describes how signaling of the set of S2L sub-LSPs can be split
>    in more than one Path message.
> s/split in more/split across more/
> ==
> Section 5.2.2
>    The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path
>    message and applies to all the S2L sub-LSPs signaled in the Path
>    message. A transit LSR MUST append its address in an incoming RRO and
>    propagate it downstream. A branch LSR MUST form a new RRO for each of
>    the outgoing Path messages by copying the RRO from the incoming Path
>    message and appending its address. Each such updated RRO MUST be
>    formed using the rules in [RFC3209].
> s/in [RFC3209]./in [RFC3209] updated by [RFC3473] as appropriate./
> ==
> Section 5.2.2
>    If a LSR is unable to support a S2L sub-LSP in a Path message, a
>    PathErr message MUST be sent for the impacted S2L sub-LSP, and normal
>    processing of the rest of the P2MP LSP SHOULD continue.
> Suggest the addition of an example...
>    If a LSR is unable to support a S2L sub-LSP in a Path message (for
>    example, it is unable to route towards the destination using the SERO), a
>    PathErr message MUST be sent for the impacted S2L sub-LSP, and normal
>    processing of the rest of the P2MP LSP SHOULD continue.
> ==
> Section 5.2.2
> s/section 12./sections 5.2.4 and 11./
> ==
> Section 5.2.3 Title
> The title of this section is ambiguous. Does the transit get fragmented?
> Suggest
> 5.2.3. Transit Fragmentation of Path State Information
> ==
> Section 5.2.3
>    It is desirable not to rely on IP
>    fragmentation in this case.
> This bald statement needs qualification and should not be left as an
> exercise for the reader.
> Presumably the reason is that IP fragmentation of RSVP messages is
> explicitly disallowed in section 3.3 of RFC2205. In which case "desirable"
> does not come into it, and this is a stronger requirement.
> However, in practice, IP fragment loss and the consequent message loss, is
> no different from IP packet loss and the consequent message loss. Or is it?
> ==
> Section 5.2.3 para 2
>    When multiple Path messages are used by an ingress or transit node,
>    each Path message SHOULD be identical with the exception of the S2L
>    sub-LSP related information (e.g., SERO),
> s/related information/descriptor/
> ==
> Section 5.2.3 para 3
>    As described above one case in which the Sub-Group Originator ID of a
>    received Path message is changed is that of transit fragmentation.
> s/transit fragmentation/fragmentation of the Path message at a transit node/
> ==
> Section 6.1
> The format of the <flow descriptor> definition has been messed up
> ==
> Section 6.1
> I don't think we should use the same name for the <S2L sub-LSP descriptor
> list> as is used for the Path message as it leads to exactly the same
> confusion and error as we have here. Viz.
>    <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP
>    SECONDARY_EXPLICIT_ROUTE> ]
> Should read...
>    <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP
>    SECONDARY_RECORD_ROUTE> ]
> (and obviously the format needs to be sorted out)
> So I suggest changing the name to be different from that used in a Path
> message as the descriptor is a different entity.
> ==
> Section 6.1 final para
>    However different upstream labels are allocated if the <Sender
>    Address, LSP-ID> of the FILTER_SPEC object is different as that
>    implies different P2MP LSP.
> s/are/MUST be/
> ==
> Section 6.2 para 1
>    The egress LSR MUST follow normal RSVP procedures while originating a
>    Resv message. The Resv message carries the label allocated by the
>    egress LSR.
> Is this the case, or does the Resv message from the egress contain an
> S2L_SUB_LSP object?
> If it is the case that the S2L_SUB_LSP MUST be included then please say so
> in this paragraph.
> If this paragraph is correct as it stands, please add a note to say that the
> S2L_SUB_LSP object MUST NOT be included.
> ==
> Section 6.2
>    Each branch node can potentially send one Resv message upstream for
>    each of the downstream receivers. This MAY result in overflowing the
>    Resv message, particularly when considering that the number of
>    messages increases the closer the branch node is to the ingress of
>    the P2MP LSP.
> As currently written, this says that one Resv message is sent for each
> downstream receiver (i.e. n messages when there are n receivers). I don't
> think you means this because the next sentence talks about overflowing which
> would not arise in this case.
>
> At the same time, the increase in the number of messages closer to the
> ingress is not relevant, it is the increase in the number of receivers.
>
> If you are *also* trying to talk about the potential of a single message per
> receiver and the impact of the consequent number of messages as you get
> closer to the ingress, with the implied desirability of combining messages
> into a single Resv, then this needs to be said separately.
>
> So...
>    Each branch node MAY forward a single Resv message upstream for
>    each received Resv from a downstream receiver. Note that there may be
>    a large number of Resv messages at and close to the ingress LSR for an
>    LSP with many receivers. To avoid issues of congestion, a branch LSR
>    SHOULD combine Resv state from multiple receivers into a single Resv
>    message to be sent upstream (see section 6.2.1), but note that this may
>    result in overflowing the Resv message particularly as the number of
>    receivers downstream of any branch LSR increases as the LSR is closer
>    to the ingress LSR. Thus, a branch LSR MAY choose to send more than
>    one Resv message upstream and partition the Resv state between the
>    messages.
> ==
> Section 6.2 final paragraph
>    Transit nodes MUST replace the Sub-Group ID fields received in the
>    FILTER_SPEC objects with the value that was received in the Sub-Group
>    ID field of the Path message from the upstream neighbor, when the
>    node set the Sub-Group Originator field in the associated Path
>    message.  ResvErr messages generation is unmodified.  Nodes
>    propagating a received ResvErr message MUST use the Sub-Group field
>    values carried in the corresponding Resv message.
> Split the ResvErr text into a second paragraph
> ==
> Section 6.2.1 para 1
>    A branch node may have to send the Resv message being sent upstream
>    whenever there is a change in a Resv message for a S2L sub-LSP
>    received from one of the downstream neighbors.
> Some problems with tense. Try...
>    A branch node may have to send a revised Resv message upstream
>    whenever there is a change in a Resv message received from one of
>    its downstream neighbors for a S2L sub-LSP.
> ==
> Section 6.2.1 para 1
> s/upstream,particularly/upstream, particularly/
> ==
> Section 6.2.1 para 1
> s/established for the first time./first established/
> ==
> Section 6.2.1 recommends the use of a timer. IETF protocol specification
> rules require that we suggest a value for all protocol timers. Please
> suggest a value here - it could be a function of some other timer, a
> function of the number of downstream destinations, or just a raw number.
> ==
> Section 6.3 Title
> "Record Routing" doesn't do it for me! What "Route Recording"?
> ==
> Section 6.3.1 para 1
>    A Resv message contains a record route per S2L sub-LSP that is being
>    signaled by the Resv message if the sender node requests route
>    recording by including a RRO in the Path message. The same rule is
>    used during signaling of P2MP LSP i.e. insertion of the RRO in the
>    Path message used to signal one or more S2L sub-LSP triggers the
>    inclusion of an RRO for each sub-LSP.
> Say either "recorded route" or "route record".
> I think this paragraph is trying to contract P2P (first sentence) with P2MP
> (subsequent sentence), but actually describes P2MP in both with the result
> that "The same rule is used..." is confusing. How about...
>    A Resv message for a P2P LSP contains a recorded route if the
>    ingress LSR requested route recording by including an RRO in
>    the original Path message. The same rule is used during signaling
>    of P2MP LSPs. That is, inclusion of an RRO in the Path message
>    used to signal one or more S2L sub-LSPs triggers the inclusion
>    of a recorded route for each sub-LSP in the Resv.
> ==
> Section 6.3.1 para 2
>    The record route of the first S2L sub-LSP is encoded in the RRO.
> s/record route/recorded route/
> ==
> Section 6.3.1 para 2
>    Additional RROs for the subsequent S2L sub-LSPs are referred to as
>    P2MP_SECONDARY_RECORD_ROUTE objects (SRROs).
> s/RROs/recorded routes/
> s/referred to as/encoded in/
> ==
> Section 6.3.1 para 2
> s/20.5/19.5/
> ==
> Section 6.3.1 para 2
>    The ingress node then receives the RRO and
>    possibly the SRRO  corresponding to each subsequent S2L sub-LSP. Each
>    <S2L_SUB_LSP> object is followed by the RRO/SRRO. The ingress node
>    can then determine the record route corresponding to a particular S2L
>    sub-LSP. The RRO and SRROs can be used to construct the end to end
>    Path for each S2L sub-LSP.
> First sentence is duplicated later and should be removed as confusing. But
> the text is wrong anyway. Rewrite as...
>    Each S2L_SUB_LSP object in a Resv is associated with an RRO or
>    SRRO. The first S2L_SUB_LSP object (for the first S2L sub-LSP) is
>    associated with the RRO. Subsequent S2L_SUB_LSP objects (for
>    subsequent S2L sub-LSPs) are each followed by an SRRO that
>    contains the recorded route for that S2L sub-LSP from the leaf up to
>    a branch. The ingress node can then determine use the RRO and
>    SRROs to determine the end-to-end path for each S2L sub-LSP.
> ==
> Section 6.4 para 1
> s/can either be FF or SE./can be either FF or SE./
> ==
> Section 6.4 para 1
>    The S2L sub-LSPs that belong
>    to different P2MP LSP MUST NOT share labels. If the reservation style
>    is FF then S2L sub-LSPs that belong to different P2MP LSP MUST NOT
>    share resources.  If the reservation style is SE than S2L sub-LSPs
>    that belong to different P2MP LSP and the same P2MP Tunnel SHOULD
>    share resources where they share hops, but MUST not share labels.
> s/different P2MP LSP/different P2MP LSPs/   (thrice)
> s/than/then/
> This text gives GMPLS a problem because SE sharing of resources in
> non-packet networks requires sharing of labels (and this is how
> make-before-break is usually performed in resource-constrained non-packet
> environments). I would suggest that the first sentence is superfluous as it
> is covered by either FF or SE. Can we rewrite as...
>    If the reservation style is FF then S2L sub-LSPs that belong to
>    different P2MP LSPs MUST NOT share resources or labels. If the
>    reservation style is SE then S2L sub-LSPs that belong to different
>    P2MP LSPs and the same P2MP Tunnel SHOULD share resources
>    where they share hops, but MUST not share labels in packet
>    environments.
> ==
> Section 7.2.2 para 2
>    A transit LSR that propagates the PathTear message downstream MUST
>    ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
>    in the PathTear message to the values used to generate the previous
>    Path message that corresponds to the S2L sub-LSPs being deleted by it
>    in the PathTear message.
> This is a bit clumsy. How about...
>    A transit LSR that propagates the PathTear message downstream MUST
>    ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
>    in the PathTear message to the values used in the Path message used to
>    set up the S2L sub-LSPs being torn down.
> ==
> Section 8.1 para 1
> s/and Notify messages/and Notify message/
> s/Both object and messages/Both object and message/
> ==
> Section 8.1 point 2. para 1
> s/to the value, that was/to the value that was/
> ==
> Section 8.1 point 2. para 1
>    If the incoming Resv message carries a
>    Notify Request object then the LSR MUST set the Notify node address
>    in the Notify Request object to the value, that was received in the
>    corresponding Path message, in the Resv message that it sends
>    upstream.
> Too many sub-clauses. Try...
>    If the incoming Resv message carries a
>    Notify Request object then the LSR MUST set the Notify node address
>    in the Notify Request object in the Resv message that it sends
>    upstream to the value that was received in the corresponding Path
>    message,
> ==
> Section 8.1
> Missing final period.
> ==
> Section 8.2 para 2
> s/to the value, that was/to the value that was/
> ==
> Section 8.2 para 2
> s/carry/carries/
> ==
> Section 8.2 final para
>    All downstream branches that do
>    requested ResvConf messages MUST be sent such a message.
> s/that do/that/
> ==
> Section 9
> s/LSP/LSPs/  (twice)
> ==
> Section 10 para 1
> Not sure what this is trying to say by "managed". Perhaps "indexed" or
> "identified" or "located"?
> ==
> section 10 para 2
> s/object/objects/
> ==
> Section 10.1 para 3
> s/4.2/5.2/
> ==
> Section 10
> Suddenly the definition of TE Router ID is given a reference to [RFC3477]
> which wasn't present in earlier uses of the term (section 5.2.1, 5.2.3).
> Firstly, we need to be consistent, but more important (to me) is that 3477
> does NOT define TE Router ID: it defines Router ID.
> You are faced, therefore with:
> - drop the reference
> - define the term yourself
> - find another reference.
> The best other reference I can find is
> draft-ietf-ccamp-gmpls-addressing-03.txt
> ==
> Section 11
> s/requests the maintenance of the 'LSP integrity'/requests the maintenance
> of  'LSP integrity'/
> ==
> Section 11
>    Therefore, reception of an
>    error message for a particular S2L sub-LSP MAY change the state of
>    any other S2L sub- LSP of the same P2MP TE LSP.
> I think this is a lowercase "may". There is no element of choice for an
> implementation here.
> ==
> Section 11.1
> Need a reference to the definition of <S2L sub-LSP descriptor list> in
> section 5.1
> ==
> Section 11.2
> Would benefit from a reference to the revised <flow descriptor list> defined
> in section 6.1
> ==
> Section 11.2
> Note the receiver of a
>    ResvErr message is able to identify the errored outgoing Path
>    message, and outgoing interface, based on the Sub-Group fields
>    received in the ResvErr message.
> This should either say "*incoming* Path" or "outgoing *Resv*"
> ==
> Section 11.3
>    A branch LSR that receives a PathErr message with the
>    Path_State_Removed flag clear MUST act according to the wishes of the
>    ingress LSR. The default behavior is that the branch LSR forwards the
>    PathErr upstream and takes no further action. However, if the LSP
>    integrity flag is set on the Path message, the branch LSR MUST send
>    PathTear on all downstream branches and send the PathErr upstream
>    with the Path_State_Removed flag set (per [RFC3473]).
> This only applied during LSP setup. That is, the LSP integrity flag does not
> impact on any LSP state once the LSP has been set up and if the PathErr does
> not have the Path_State_Removed flag set. (Compare with the first paragraph
> of this section.) So this paragraph should read...
>    A branch LSR that receives a PathErr message during LSP setup with the
>    Path_State_Removed flag clear MUST act according to the wishes of the
>    ingress LSR. The default behavior is that the branch LSR forwards the
>    PathErr upstream and takes no further action. However, if the LSP
>    integrity flag is set on the Path message, the branch LSR MUST send
>    PathTear on all downstream branches and send the PathErr upstream
>    with the Path_State_Removed flag set (per [RFC3473]).
> ==
> Section 14.2 para 1
> s/the incremental/incremental/
> ==
> Section 15
> Please change
>    [RFC4090] extensions can be used to perform fast reroute for the
>    mechanism described in this document.
> to
>    [RFC4090] extensions can be used to perform fast reroute for the
>    mechanism described in this document when applied within packet
>    networks.
> ==
> Section 15.1 .1
> This text is particularly dense and would benefit from re-writing and
> paragraph breaks.
> Some non-exhaustive comments follow.
> ==
> Section 15.1.1
> The two uses of "MUST" seem to be overkill.
> RFC 4090 only uses "SHOULD" for P2P LSPs.
> ==
> Section 15.1.1
>    Note that all such S2L sub-LSPs belonging to a particular instance of
>    a P2MP tunnel will share the same outgoing label on the link between
>    the PLR and the next-hop.
> This is only a "SHOULD share labels" in section 5.2.1.
> Not a big deal. Just delete this and the subsequent sentence.
> ==
> Section 15.1.1
> Paragraph break before
>    During failure Path messages for each S2L sub-LSP, that are
>    effected, MUST be sent to the MP, by the PLR.
> which should be rewritten as
>    During failure, Path messages for each S2L sub-LSP that is
>    affected MUST be sent to the MP by the PLR.
> ==
> Section 15.1.1
> s/It is recommended that/It is RECOMMENDED that/
> ==
> Section 15.1.1
> s/the PLR use/the PLR uses/
> ==
> Section 15.1.1
> s/sender template specific/sender template-specific/
> ==
> Section 15.1.1
> Paragraph break before
>    The MP MUST use
> ==
> Section 15.1.1
> Change
>    The MP MUST use the LSP-ID to
>    identify the corresponding S2L sub-LSPs. The MP MUST not use the
>    <sub-group originator ID, sub-group ID> while identifying the
>    corresponding S2L sub-LSPs. In order to further process a S2L sub-LSP
>    the MP MUST determine the protected S2L sub-LSP using the LSP-id and
>    the <S2L_SUB_LSP> object.
> to
>    The MP MUST use the LSP-ID and the <S2L_SUB_LSP> object to
>    identify the corresponding S2L sub-LSPs. The MP MUST not use the
>    <sub-group originator ID, sub-group ID> to identify the
>    corresponding S2L sub-LSPs because the sub-group
>    originator ID might be changed by some LSR that is bypassed
>    by the bypass tunnel.
> ==
> Section 15.1.1
> Please add the following.
>    Note that these procedures may require that the PLR replicate
>    data for a P2MP LSP into more than one bypass tunnel where
>    the LSR was not previously responsible for replicating this
>    data. This can arise if there are several MPs that are not one
>    hop downstream of the PLR. Further, in this case, the
>    replicated data may be required to be labeled with a
>    two-label label stack where both labels are different in each
>    copy of the data.
> ==
> Section 15.1.2
> Again, the use of "MUST" is stronger than RFC 4090
> ==
> Section 15.1.2
>    The MP MUST allocate the same label to all such S2L sub-LSPs
>    belonging to a particular P2MP LSP.
> I think you cannot make this constraint. The MP doesn't necessarily know
> that it is going to be an MP when it allocates the label for the S2L
> sub-LSP. Besides, 5.2.1 has already allowed separate labels.
> But this isn't an issue is it? If there are two labels there are already two
> copies of the data.
> ==
> Section 15.1.2 para 2
>    After detecting failure of the protected node the PLR MUST send a
>    Path message for each protected S2L sub-LSP to the MP of the
>    protected S2L sub-LSP.
> This implies one Path message for each S2L sub-LSP is that really the case?
> Since we have a mechanism for placing more than one S2L sub-LSP in a Path
> message, we could certainly use this here.
> ==
> Section 15.1.2 para 2
> s/recommended/RECOMMENDED/
> ==
> Section 15.1.2 para 2
> s/MUST not/MUST NOT/
> ==
> Section 15.1.2 para 2
> Similar changes as in 15.1.1 wrt "while identifying"
> ==
> Section 15.2 para 2
> Unlike the bypass stuff, the detour work seems a bit rocky. Perhaps no-one
> has implemented it yet?
>    One to one backup as described in [RFC4090] can be used to protect a
>    particular S2L sub-LSP against link and next-hop failure. Protection
>    may be used for one or more S2L sub-LSPs between the PLR and the
>    next-hop. All the S2L sub-LSPs corresponding to the same instance of
>    the P2MP tunnel, between the PLR and the next-hop share the same P2MP
>    LSP label.
> This leaves me uneasy.
> Firstly, the statement about using the same label is in contradiction with
> section 5.2.1.
> But also, it seems to me odd that you are talking about protecting S2L
> sub-LSPs rather than about protecting the P2MP LSP. True, you may achieve
> the protection of the P2MP LSP by protecting each constituent S2L sub-LSP,
> but if you start with the discussion of S2L sub-LSPs it implies that you
> could protect sub S2L sub-LSPs within one P2MP LSP and not others. This
> would appear to be a contradiction of the statement that all leaves of the
> tree have the same LSP attributes.
> So I think it would be helpful to spend some time reworking this text in
> terms of the P2MP LSP.
> ==
> Section 15.2 para 2
>    All or some of these S2L sub-LSPs may be protected.
> This seems to confirm my worst fears, but it is also damnably strange.
> Consider: you have said that all of the S2L sub-LSPs use the same label.
> Notwithstanding that I disagree with you, let us assume that they do. How
> then would you protect only a subset of them? There is only one copy of the
> data.
> ==
> Section 15.2 para 2
>    The detour S2L sub-LSPs may or may not share labels, depending on the
>    detour path. Thus the set of outgoing labels and next-hops for a P2MP
>    LSP that was using a single next-hop and label between the PLR and
>    next-hop before protection, may change once protection is triggerred.
> Why would the label sharing for the detour LSPs (please don't call them
> "detour S2L sub-LSPs" because they really don't go from the S or to the L)
> behave differently from the protected LSPs?
> I *think* you are setting yourself up for different MPs depending on the
> leaves. But you didn't describe this process for bypass tunnels where it is
> surely equally applicable.
> ==
> Section 15.2 para 4
> s/recommended/RECOMMENDED/
> ==
> Section 16 para 7
>    The ingress can use IGP
>    extensions to determine non P2MP capable LSRs [TE-NODE-CAP].
> Well, strictly it uses the extensions to determine P2MP-capable LSRs and can
> then make assumptions that the other LSRs are either shy or not capable of
> P2MP function.
> ==
> Section 16 para 7
>    The P2MP
>    capable LSR that initiates the non-adjacent signaling message to the
>    next P2MP capable LSR may have to employ a fast detection mechanism
>    such as [BFD] [BFD-MPLS] to the next P2MP capable LSR.
> Please break this into the subsequent paragraph that contains the
> explanation.
> ==
> Section 17 para 1
> s/up P2MP LSP/up a P2MP LSP/
> s/Infact/In fact/
> ==
> Section 17 para 2
> s/P2P LSPs be dynamically setup/P2P LSPs can be dynamically set up/
> ==
> Section 17 para 2
> Not sure that a reference to a figure in the Appendix is appropriate. I
> think Appendixes are normally non-normative.
> ==
> Section 18 para 1
> Strike it
> ==
> Section 18 para 4
>    Normally, a P2MP LSP has a single incoming interface on which all of
>    the Path messages associated with that P2MP LSP are received.
> Mustn't describe the interfaces in terms of how the Path messages are
> received (see the very next sentence!). Let's keep to the data plane to
> avoid the issue.
>    Normally, a P2MP LSP has a single incoming interface on which all of
>    the data for the P2MP LSP is received.
> ==
> Section 18 para 5
>    Similarly, in both the re-merge case and cross-over cases, a node
>    will receive a Path message for a given P2MP LSP on a different
>    incoming interface, and the node needs to be able to distinguish
>    between dynamic LSP re-routing and the re-merge/cross-over cases.
> Same issue...
>    Similarly, in both the re-merge case and cross-over cases, a node
>    will receive a Path message for a given P2MP LSP identifying a
>    different incoming interface for the data, and the node needs to be
>    able to distinguish between dynamic LSP re-routing and the
>    re-merge/cross-over cases.
> ==
> Section 18.1 para 2
> s/SUB-LSP objects/S2L_SUB_LSP objects/   (three times)
> s/ set of SUB-LSPs/ set of S2L sub-LSPs/
> ==
> Section 18.1.1 para 2
> s/objects included the/objects included in the/
> ==
> Section 18.1.1 para 3
> s/followed for both/followed for all/
> ==
> Section 18.1.1 para 4
>    When configured to allow a re-merge case to persist, the re-merge
>    node receives data associated with the P2MP LSP on multiple incoming
>    interfaces, but it may only send the data from one of these
>    interfaces to its outgoing interfaces,
> s/may/MUST/
> ==
> Section 18.1.1 paras 5, 6 and 7
> s/SUB-LSP objects/S2L_SUB_LSP objects/   (six times)
> ==
> Section 19.1.1 Extended Tunnel ID
> s/ingress-PID/ingress-P2MP ID/
> ==
> Section 19.2 para 1
> s/ingress-LSR/ingress LSR/
> s/LSP ID can be can be/LSP ID can be/
> ==
> Section 19.2 para 1
>    The instances can share
>    resources with each other, but use different labels.
> Either strike ", but use different labels" or change to ", but may use
> different labels."
> ==
> Section 19.2.1 and 19.2.2
> This is a bit hairy, but...
> The Sub-Group Originator and the source do not necessarily come from the
> same IPv4/6 spaces. So you might need to add an IPv6 Sub-Group Originator to
> a Sender_Template that has an IPv4 sender address.
> I don't like the sound of this, because it creates four flavours instead of
> the two listed, and it doesn't seem very likely to occur in the field.
> What do we do? Leave it as it is and wait until someone encounters the
> issue?
> ==
> Section 19.2.2
> I think you can use the same short-form text as used in 19.1.2 and save some
> trees.
> ==
> Section 19.3.1 and 19.3.2
> s/SUB_LSP Class = 50/S2L_SUB_LSP Class = 50/
> ==
> Section 19.4.2 Title
> s/4/6/
> ==
> Section 20
> The whole of this section needs to give IANA a better reference for where
> the new code points are to be allocated. This can be done by naming the
> registries (with the IANA pages).
> ==
> Section 20.1
> s/50  Class Name = SUB_LSP/50  Class Name = S2L_SUB_LSP
> ==
> Section 20.2
> s/P2MP LSP/P2MP_LSP/    (thrice)
> ==
> Section 20.3
> For reference I have tracked these values in the interim registry of Routing
> Problem error values at http://www.olddog.co.uk/ccamp.htm
> ==
> Section 20.4
>    Referenced Section of this Doc:   10
> s/10/5.2.4/
> For reference I have tracked these values in the interim registry of
> LSP_ATTRIBUTE flags at http://www.olddog.co.uk/ccamp.htm
> ==
> Section 21
> Absolutely no way we will get away with a 3 line security section! The
> security ADs are positively mauling all I-Ds at the moment.
> There are a couple of things we can say:
> - more destinations for an LSP increases the risk
> - there is potential for a listener to get themselves added to a P2MP tree
> - there is description in the I-D about using tunnels to form remote
> adjacencies
> - DoS impact when one leaf is nobbled and the tree has LSP integrity applied
> Probably lots more.
> ==
> Section 23
> Usual to put the appendix later in the document
> ==
> Section 23.1 point a)
>   We assume that PE1 learns of the
>    egress-LSRs at different points.
> "points in time" ?
> ==
> Section 24.2
> Suspect that some of the I-D versions listed have moved on
> ==
> Section 25.2
> Lou and Markus's coordinates have changed
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
>

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