The MPLS WG Archive

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

Hi,

I know that the RFC editor will reformat, etc., but I do feel that I-Ds
should be presentable when they come up for last call. It would make the
review process so much easier.

This document needs significant editorial work before it can be
progressed.

Section 1
Bypass Tunnel defined but not used. Please delete or indicate that this a
synonym for "backup tunnel".
CSPF defined but not used. Please delete.
You feel it necessary to define ASBR, but not ABR. Odd.
LER defined but not used.
LSDB defined but not used.
PCC and PCE. PCC is not used at all. PCE gets a single reference. While I
love PCE dearly, I think this reference is not helpful because:
- it is not in the section stated
- it is given without any explanation
- there are no wider references in the references sections
- the use of PCE is not fundamental to the document.
I suggest removing PCC and PCE completely.

Where Section 1 definitions in this document are copied from RFC4090,
would it not be better to refer the reader to RCF4090 instead?

The definition of MP could usefully be revised to read
    MP: Merge Point. The LSR where detour or backup tunnels meet the
    protected LSP. A MP may also be a PLR for a different backup tunnel.
- No need to talk about one-to-one since this document doesn't deal in
detours
- An MP cannot be a PLR for the same backup tunnel!

The definition of PLR should be revised as
   PLR: Point of Local Repair. The head-end of a backup tunnel.
- No need to talk about detours since this document doesn't deal in
one-to-one backup.

The first paragraph of section 2 states that in FRR the protected LSPs are
rerouted "in tens of msecs". I am not sure of the value of this marketing
statement. The earth goes around the Sun in tens of msecs - a lot of tens.
OTOH, the speed of rerouting is an implementation issue. Since RFC4090
defines FRR and since the mechanism is accepted and deployed, we do not
need the sales blurb.

Section 2 states that the PLR "should be" at the head end of the backup
tunnel and that the MP "should be" at the tail end of the backup tunnel.
Don't you mean "is" in both cases?

Section 2 rather casually states that the inter-area technique just
described can also be applied to inter-AS. As Hemanth just asked on the
MPLS list, what happens when ASs use overlapping address spaces? Also,
what happens when ASs apply confidentiality at the AS border?

Step 1 in section 2 is confused/confusing
>  1. The backup tunnel intersects with the primary tunnel at the MP
>    (and thus has a valid MP address). For the sake of illustration,
>     in Figure 1, R1 needs to determine that T1 and B1 share the same
>     MP node R2.
This should be rephrased in line with the definition of MP. I.e. you can't
"share an MP". You select an MP.
What does "has a valid MP address" mean? How could an MP have an invalid
address?

In step 2 in section 2, what is meant by "(preferably, protecting against
a node failure versus a link failure)". The PLR may prefer node protection
to link protection, but it has no choice. Are you attempting to make a
statement about the protection type that the ingress should request?

The subsequent paragraph is odd.
> A PLR can make sure that condition (1) is met by examining the Record
> Route Object (RRO) of the primary tunnel to see if any of the addresses
> specified in the RRO is attached to the tail-end of the backup tunnel.
The implication here is that you have built a backup tunnel "at random"
and you are now seeing if it is any use to protect your primary LSP. If it
is the case that you are choosing between a set of existing backup tunnels
to see which is suitable, then please make this far clearer. If, on the
other hand, the backup tunnel is signaled to satisfy the requirements of
the primary LSP (as you have previously indicated) then clearly the
process described here is broken. My feeling is that your current text may
reflect a deployment model where bypass tunnels are manually configured
and selected as needed.
I suspect you need both steps. First see if any existing bypass tunnel is
suitable. Then set up a new bypass tunnel dynamically.

Why are there two section 2s?

In the second section 2, you should point out that legacy LSRs that do not
support setting the new 0x20 bit may still supply sufficient information
for the purpose. That is, they may still supply an RRO subobject of type
IPv4 or IPv6 containing the TE Router ID of the LSR and this can be used
to determine the MP. In this respect, the use of the 0x20 bit is a minor
optimization that helps the PLR parse the RRO rapidly.

In the second section 2...
>Node-id: 0x20
>      When set, this indicates that the address specified in the
>      RRO's IPv4 or IPv6 subobject is a node-id address, which refers
>      to the "Router Address" as defined in [OSPF-TE], or "Traffic
>      Engineering Router ID" as defined in [ISIS-TE]. A node MUST use
>      the same address consistently. Once an address is used in RRO's
>      IPv4 or IPv6 subobject, it should always be used for the
>      lifetime of the LSP.
s/should/SHOULD/

Section 4
Since you are dealing with protocol extensions that cross AS boundaries,
you are necessarily introducing new security/confidentiality issues. At
the very least you need to discuss the fact that ASBRs might normally
choose to strip (or aggregate) the RRO at the ASBR. You have introduced a
requirement that modifies this behavior.
You also need to point out the significant security issue of mis-selection
of a bypass tunnel since this may lead to mis-connection and mis-delivery.
(Of course, this item should have been in the security section of RFC
4090, but it isn't.) Arguably, this issue is considerably more important
in inter-domain networks.

Section 5
I don't believe that IANA currently manages this name space.
If you require IANA to create a new name space you will need to explain it
and define the circumstances under which assignments can be made.

Section 8.1
RFCs 3667 and 3668 have been obsoleted.

Thanks,
Adrian



----- Original Message ----- 
From: "The IESG" <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: <mpls@ietf.org>
Sent: Thursday, July 14, 2005 6:09 PM
Subject: Last Call: 'Definition of an RRO node-id subobject' to Proposed
Standard


> The IESG has received a request from the Multiprotocol Label Switching
WG to
> consider the following document:
>
> - 'Definition of an RRO node-id subobject '
>    <draft-ietf-mpls-nodeid-subobject-06.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-28.
>
> The file can be obtained via
>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-nodeid-subobject-06.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>


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