Subject: Re: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt (fwd)

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 20 Jun 2006 12:30:39 -0700 (PDT)

Hi Adrian,

Sorry for the delay. Please see inline:

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.

Fixed.

> ==
> Abstract
> s/setup/set up/
> (setup is a noun not a verb)

Ok.

> ==
> Abstract
> Looks like you want a paragraph break before...
> "There can be various applications..."

Ok.

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

Ok.

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

Ok.

> ==
> Section 3 para 4
> s/application specific/application-specific/

Ok.

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

Will fix this.

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

Ok.

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

This paragraph needs to be actually been modified differently based on the
discussion on Tunnel ID and Extended Tunnel ID semantics. See below:

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

The above paragraph and this should be modified to the following based on
the Tunnel ID, Extended Tunnel ID discussion:

" 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 a tuple
<Ingress LSR IP address, P2MP Identifier>, where the P2MP Identifier (P2MP
ID) is a four octet number and is unique within the scope of the IP
address of the ingress LSR. The Ingress LSR IP address is encoded in the
Extended Tunnel ID. The P2MP Tunnel identifier, carried in the P2MP SESSION
object, is unique within the same scope as the ingress LSR IP address.

The fields of the 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 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.

Ok.

> ==
> Section 4.2
> s/20.2/19.2/

Ok.

> ==
> Section 4.3 para 3
> s/subgroup/sub-group/
> Please do global search and replace in the document

Ok.

> ==
> Section 4.3 para 3
> s/an egress and semantic/an egress, and semantic/

Ok.

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

Ok.

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

Ok.

> ==
> Section 4.4.1
> It seems to me that the S2L_SUB_LSP object contains a leaf identifier and an
> SERO.

No. It contains only the destination address. Please see section 19.3.

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

I will wait to comment on this, as it appears to be be predicated on
interpretation of the S2L_SUB_LSP object.

> ==
> Section 4.4.2 para 1
> s/setup/set up/

Ok.

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

Ok.

> ==
> 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"

Ok.

> ==
> Section 4.5 para 3
> s/(as defined in [RFC3209])/(as defined in [RFC3209] and [RFC3473])/

Ok.

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

That is not correct. Please see below on this point.

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

Ok.

> Section 4.5 para 3
> s/20/19/
> ==
> Section 4.5 para 6
> s/Following/The following/
> Also near the top of page 10.

Will replace by "The following encoding"

> ==
> Section 4.5
> s/exercise to the reader./exercise for the reader./
> ==

Ok.

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

Ok.

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

That is not correct. From the text:

"The first S2L_SUB_LSP object's explicit route is specified by the
ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the
corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP
object."

To explain further, the ERO is specifying the explicit route of the first
S2L_SUB_LSP. If there is only one S2L_SUB_LSP, there is no need for a
SERO. Since it is optional in the BNF, this is correct. If there is indeed
a second S2L_SUB_LSP, the preceding SERO specifies its path. This is
consistant with the fact that the ERO specifies the path of the first
S2L_SUBLP i.e. the ordering is always <explicit-route/sub-explicit-route,
sub-lsp>.

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

Which LSP are you referring to ?

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

Ok.

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

Will replace with SHOULD share.

> ==
> Section 5.2 para 1
> s/identified using the <S2L_SUB_LSP> object/identified using the
> <S2L_SUB_LSP> objects/

The current text seems to be fine in this case:

"Each S2L sub-LSP is identified using the S2L_SUB_LSP object."

> ==
> Section 5.2 para 2
> s/20/19/
> ==

Ok.

> Section 5.2.1 para 1
> You have changed your notation for tuples
> ==

Fixed.

> Section 5.2.1 para 3
>    An ingress LSR may use multiple Path messages for signaling a P2MP
>    LSP.
> s/may/MAY/

Ok.

> ==
> 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/
> ==

Ok.

> 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/
> ==

Will replace "each of the messages carry" with "each message 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/
> ==

It is a single field, so the current text is correct.

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

Ok.

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

Will rephrase:

"The <Sub-Group Originator ID, sub-Group ID> tuple is
globally unique. 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."

to:

"The Sub-Group Originator ID is globally unique. The sub-Group ID space
is specific to the Sub-Group Originator ID."

This leaves the decision of how Sub-Group IDs are managed to the LSR with
the Sub-Group originator ID.

> ==
> 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"?

I agree that this is redundant. Will remove it.

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

Ok.

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

Ok.

> 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/
> ==

Ok.

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

Ok.

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

Ok.

> Section 5.2.2
> s/section 12./sections 5.2.4 and 11./

Ok.

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

Ok.

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

How about rephrasing the above to:

"RSVP [RFC2205] disallows the use of IP fragmentation and thus IP
fragmentation must be avoided in this case."

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

I am not sure this matters in light of the above rephrasing and the text
in RFC2205.

> ==
> 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/

Ok.

> ==
> 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/

Ok.

> ==
> 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)

Will fix the typo. The format is correct as I pointed out in response to
a similar comment above in the Path message.

> So I suggest changing the name to be different from that used in a Path
> message as the descriptor is a different entity.

Ok. Will use: "S2L sub-LSP flow descriptor" here.

> ==
> 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/

Ok.

> ==
> 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?

It does.

> If it is the case that the S2L_SUB_LSP MUST be included then please say so
> in this paragraph.

Ok. Will rephrase to: "The egress-LSR MUST include a S2L sub-LSP
descriptor in the flow descriptor or SE filter spec sent upstream in a
Resv message and follow normal RSVP produres while originating a Resv
message. The Resv message carries the label allocated by the
egress LSR."

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

How about with some minor changes to your proposal:

" Each branch node MAY forward a single Resv message upstream for
each received Resv message 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. 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

Ok.

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

Ok.

>Section 6.2.1 para 1
> s/upstream,particularly/upstream, particularly/

Ok.

> ==
> Section 6.2.1 para 1
> s/established for the first time./first established/

Ok.

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

Let us pick 30 seconds and keep this simple, leaving tweaks to
implementations as suggested by the following text.

> Section 6.3 Title
> "Record Routing" doesn't do it for me! What "Route Recording"?
> ==

Ok.

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

Ok.

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

Ok.

> ==
> 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/

Ok.

> ==
> Section 6.3.1 para 2
> s/20.5/19.5/
> ==

Ok.

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

This is fine except for "followed" has to replaced by "preceded". Also an
extra determine in the second last sentence.

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

Ok.

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

Ok.

> Section 8.1 para 1
> s/and Notify messages/and Notify message/
> s/Both object and messages/Both object and message/
> ==

Ok.

> Section 8.1 point 2. para 1
> s/to the value, that was/to the value that was/
> ==

Ok.

> 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,
> ==

Ok.

> Section 8.1
> Missing final period.

Ok.

> ==
> Section 8.2 para 2
> s/to the value, that was/to the value that was/
> ==

Ok.

> 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/
> ==

Ok.

> Section 9
> s/LSP/LSPs/  (twice)
> =

Ok.

=
> Section 10 para 1
> Not sure what this is trying to say by "managed". Perhaps "indexed" or
> "identified" or "located"?

identified seems fine.

> ==
> section 10 para 2
> s/object/objects/
> ==

Ok.

> Section 10.1 para 3
> s/4.2/5.2/
> ==

Ok.

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

How about replacing TE Router ID with Router ID ?

> Section 11
> s/requests the maintenance of the 'LSP integrity'/requests the maintenance
> of  'LSP integrity'/
> ==

Ok.

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

Ok.

> ==
> Section 11.1
> Need a reference to the definition of <S2L sub-LSP descriptor list> in
> section 5.1

OK.

> ==
> Section 11.2
> Would benefit from a reference to the revised <flow descriptor list> defined
> in section 6.1

Ok.

> ==
> 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*"
> ==

Modified to 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]).
> ==

Ok.

> Section 14.2 para 1
> s/the incremental/incremental/
> ==

Ok.

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

Ok.

> Section 15.1 .1
> This text is particularly dense and would benefit from re-writing and
> paragraph breaks.

I will make changes only as per the specific comments that you have as
part of last call.

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

I will replace the second MUST to SHOULD.

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

This and the following sentence help to understand the procedures. I will
replace will with SHOULD and point to 5.2.1.

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

Ok.

> Section 15.1.1
> s/It is recommended that/It is RECOMMENDED that/
> ==

Ok.

> Section 15.1.1
> s/the PLR use/the PLR uses/
> ==

Ok.

> Section 15.1.1
> s/sender template specific/sender template-specific/
> ==

Ok.

> Section 15.1.1
> Paragraph break before
>    The MP MUST use
> ==

Ok.

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

The real reason has to do with node protection and to keep the procedures
consistant. I think the current text here is fine, but I can add a
clarification in the node protection case - see below.

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

This is incorrect as this will not happen with link protection. It may
happen with node protection and is described in the node protection
section.

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

I believe the label stacking text in the first para of this section
already covers this.

> Section 15.1.2
> Again, the use of "MUST" is stronger than RFC 4090
> ==

Will replace it to SHOULD.

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

The text is basically saying that for a set of S2L sub-LSPs, belonging to
a P2MP LSP, to which the MP assigned the same label, the PLR sends a
single copy of the packet to the MP with the outer label being the bypass
label.

I will modify the text as follows to clarify this:

"When the PLR forwards incoming data for a P2MP LSP into the bypass
tunnel, the outer label is the bypass tunnel label and the inner
label is the label allocated by the MP to the set of S2L sub-LSPs
belonging to that P2MP LSP. "

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

Sure. Modified text:

"After detecting failure of the protected node the PLR MUST send one
or more Path message for all protected S2L sub-LSPs to the MP of the
protected S2L sub-LSP."

> Section 15.1.2 para 2
> s/recommended/RECOMMENDED/
> ==

Ok.

> Section 15.1.2 para 2
> s/MUST not/MUST NOT/
> ==

Ok.

> Section 15.1.2 para 2
> Similar changes as in 15.1.1 wrt "while identifying"
> ==

Will incorporate it here.

> Section 15.2 para 2
> Unlike the bypass stuff, the detour work seems a bit rocky. Perhaps no-one
> has implemented it yet?

P2P Detours are implemented and deployed.

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

Will clarify this to a SHOULD as in 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.

Its just easier to describe detours that way.

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

We can add text to clarify that all s2l-sub lsps within one P2MP LSP
should be protected. This will be consistant with the wordign in section
5.

See below:

> So I think it would be helpful to spend some time reworking this text in
> terms of the P2MP LSP.

I think to overcome your comments, this is not necessary.

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

Reword this to:

"All such S2L sub-LSPs belonging to a P2MP LSP MUST be protected."

> ==
> 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)

I will use the term backup S2L sub-LSPs.

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

It is appliable only for node protection in the bypass case and is
described. It is not applicable for link protection.

Will rephrase: "The detour S2L sub-LSPs may or may not share labels,
depending on the detour path" to

"The backup S2L sub-LSPs may traverse different next-hops at the PLR.
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. This MAY require
a PLR to be branch capable in the data plane. If the PLR is not branch
capable, the one to one backup mechanisms described here are only
applicable
to those cases where all the backup S2L sub-LSPs pass through the same
next-hop downstream of the PLR. Procedures for one to one backup when
a PLR is not branch capable and all the backup S2L sub-LSPs do not
pass through the same downstream next-hop are for further study."

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

Will remove non.

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

Ok.

> ==
> Section 17 para 1
> s/up P2MP LSP/up a P2MP LSP/
> s/Infact/In fact/

Ok.

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

Will include the figure here if this comes up in the IESG review.

> ==
> Section 18 para 1
> Strike it
> ==

Why ?

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

Ok.

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

Ok.

> 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/
> ==

Ok.

> 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/
> ==
>

Ok.

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

Ok.
 ==
> Section 18.1.1 paras 5, 6 and 7
> s/SUB-LSP objects/S2L_SUB_LSP objects/   (six times)
> =

Ok.
=
> Section 19.1.1 Extended Tunnel ID
> s/ingress-PID/ingress-P2MP ID/
> ==
>

This will change as per the last call comments on tunnel ID and extended
tunnel ID. Will be revised to:

"A 32-bit identifier used in the SESSION object that remains
   constant over the life of the P2MP tunnel. This identifier
   MUST be set to the ingress LSR's IPv4 address."

Section 19.2 para 1
> s/ingress-LSR/ingress LSR/
> s/LSP ID can be can be/LSP ID can be/
> ==

Ok.

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

Did the former.

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

Forcing both sender address and sub-group originator ID to be both v4 or
both v6, seems reasonable at present.

> ==
> Section 19.2.2
> I think you can use the same short-form text as used in 19.1.2 and save some
> trees.

I left it as is because there are two v6 terms and the currrent text/ascii
is more explanatory.

> ==
> Section 19.3.1 and 19.3.2
> s/SUB_LSP Class = 50/S2L_SUB_LSP Class = 50/
> ==

Ok.

> 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)
> ==

Ok.

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

Ok.

> 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

Why ?

> - there is potential for a listener to get themselves added to a P2MP tree

I don't see how this is within the scope of this ID.

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

Can you provide some text ? Thanks.

> ==
> Section 23
> Usual to put the appendix later in the document

I moved it after the references.

> ==
> Section 23.1 point a)
>   We assume that PE1 learns of the
>    egress-LSRs at different points.
> "points in time" ?

Ok.

> ==
> Section 24.2
> Suspect that some of the I-D versions listed have moved on
> =

I will double check.

=
> Section 25.2
> Lou and Markus's coordinates have changed
>

Do you have the new co-ordinates ?

Thanks for the detailed comments.

rahul

>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
>

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls