The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

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