Subject: Last Call on Fast Reroute

From: George Swallow <[email-masked]>
Date: Tue, 03 Dec 2002 17:49:56 -0500

This message begins a workgroup last call on:

Fast Reroute Extensions to RSVP-TE for LSP Tunnels
    
  draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt

The last call ends on Dec 16, 2002 2400H GMT.

George & Loa

======================================================================
George Swallow          Cisco Systems                   (978) 497-8143
                        250 Apollo Drive
                        Chelmsford, Ma 01824

---

From: Shahram Davari <[email-masked]>
Date: Wed, 4 Dec 2002 13:30:35 -0800

Hi,

Although I have no hope of getting any response, but here is a repeat of my ignored comments raised in March, 2002 and some new ones:

1) Time stamp: Why is the time stamp in both seconds and microseconds? The microsecond could count up to 71 minutes. Isn't that enough? Why isn't the
same timestamp used in ICMP not used here which says:
 
        The Timestamp is a right-justified, 32-bit timestamp in
        milliseconds since midnight UT. 
 
2) Section 3: Why the echo reply time stamp is not similar to ICMP echo-reply time-stamp in which a received time-stamp and sent-time stamp is set by the receiver? Which gives you the processing time at the receiver too. 

3) Section 3.1: If I understand it correctly a Target FEC TLV could consist of a number of FEC stack sub-TLVs. Therefore it seems that the number of these sub-TLVs could be determined by looking at the Target FEC TLV length field and subtracting the sub-TLV lengths from it. But the text says it could be determined by looking at the sub-TLV length field. Needs clarification.

4) Section 3.1: How can you ping multiple FECs simultaneously (i.e., piggy back multiple pings), while each FEC belongs to a different level of the label stack? This requires that all those hierarchical labels (LSPs) be initiated and terminated at the same LSRs. Also how do you intend to generate error response if the result of some of those FEC pings are positive and some are negative?

5) Section 3 under return code. There is no return code for the case that one of the FECs fail while others pass, or when one of the label mappings don't pass, while others pass.

6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to the same LSP level? It seems that if 1000s of FECs are all mapped to the same LSP, then 1000's of MPLS-pings are required.

7) Why is the downstream label field in the downstream mapping TLV 24 bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit?

8) Section 3.2: When X receives a packet with TTL of n>1, shouldn't it compute the downstream LSRs that could receive the packet with TTL=n-1 (rather than TTL=n+1 as indicated)?

9) Section 3.2 last paragraph: Does this apply to trace-route mode only?

10) Section 4.3: Does the downstream mapping TLV of the echo-reply replace the downstream mapping TLV of the echo-request or it is appended to it?

11) Section 4.5: If the egress for an FEC stack being pinged doesn't support MPLS ping, isn't an ICMP TTL expire message generated for the IP TTL=1 received (instead of no reply as mentioned in the draft)?

12) Section 5 2nd paragraph last sentence I think should be changed to: "Note that this may not work if some transit LSR does not support IP options" (not 'MPLS ping' as mentioned in the draft)

13) Section 5: Is RSVP-TE return path used only in "ping" mode or also in trace-route mode?

14) Section 5.3 last paragraph: I think you need to delete ICMP here. It has no meaning here.

15) Section 5.5: I think you need to mention that if intermediate LSRs don't support refresh reduction, then it could take many minutes before the echo-reply is received at the source.

16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and how is it encoded?

17) Section 3.2: Why are there multiple downstream labels in the downstream mapping? do they belong to different LSP levels? Or the figure is simply showing many downstream mapping TLVs? 

18) Section 3.3: what is the purpose of Pad TLV?

19) Section 4.3: Should an Echo reply always have a downstream mapping TLV even if no downstream mapping TLV is in the Echo request?

20) Section 4.4: Seems like back to back echo-request can't be sent before receiving the echo-reply of previous echo-request. Why this limitation?

21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP-TE.

Thanks,
-Shahram

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 5:50 PM
> To: [email-masked]
> Subject: Last Call on Fast Reroute
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 4 Dec 2002 13:43:45 -0800

Hi,

Please ignore my last email with this subject. I intended the
comments for MPLS-ping.

Thanks,
-Shahram

> From: Shahram Davari 
> Sent: Wednesday, December 04, 2002 4:31 PM
> To: 'George Swallow'; [email-masked]
> Subject: RE: Last Call on Fast Reroute
> 
> 
> Hi,
> 
> Although I have no hope of getting any response, but here is 
> a repeat of my ignored comments raised in March, 2002 and 
> some new ones:
> 
> 1) Time stamp: Why is the time stamp in both seconds and 
> microseconds? The microsecond could count up to 71 minutes. 
> Isn't that enough? Why isn't the
> 2) Section 3: Why the echo reply time stamp is not similar to 
> ICMP echo-reply time-stamp in which a received time-stamp and 
> sent-time stamp is set by the receiver? Which gives you the 
> processing time at the receiver too. 
> 
> 3) Section 3.1: If I understand it correctly a Target FEC TLV 
> could consist of a number of FEC stack sub-TLVs. Therefore it 
> seems that the number of these sub-TLVs could be determined 
> by looking at the Target FEC TLV length field and subtracting 
> the sub-TLV lengths from it. But the text says it could be 
> determined by looking at the sub-TLV length field. Needs 
> clarification.
> 
> 4) Section 3.1: How can you ping multiple FECs simultaneously 
> (i.e., piggy back multiple pings), while each FEC belongs to 
> a different level of the label stack? This requires that all 
> those hierarchical labels (LSPs) be initiated and terminated 
> at the same LSRs. Also how do you intend to generate error 
> response if the result of some of those FEC pings are 
> positive and some are negative?
> 
> 5) Section 3 under return code. There is no return code for 
> the case that one of the FECs fail while others pass, or when 
> one of the label mappings don't pass, while others pass.
> 
> 6) Why doesn't the MPLS ping permit pinging multiple FECs 
> that belong to the same LSP level? It seems that if 1000s of 
> FECs are all mapped to the same LSP, then 1000's of 
> MPLS-pings are required.
> 
> 7) Why is the downstream label field in the downstream 
> mapping TLV 24 bits? Is it for ATM? How is the 20 bit label 
> mapped to this 24 bit?
> 
> 8) Section 3.2: When X receives a packet with TTL of n>1, 
> shouldn't it compute the downstream LSRs that could receive 
> the packet with TTL=n-1 (rather than TTL=n+1 as indicated)?
> 
> 10) Section 4.3: Does the downstream mapping TLV of the 
> echo-reply replace the downstream mapping TLV of the 
> echo-request or it is appended to it?
> 
> 11) Section 4.5: If the egress for an FEC stack being pinged 
> doesn't support MPLS ping, isn't an ICMP TTL expire message 
> generated for the IP TTL=1 received (instead of no reply as 
> mentioned in the draft)?
> 
> 12) Section 5 2nd paragraph last sentence I think should be 
> changed to: "Note that this may not work if some transit LSR 
> does not support IP options" (not 'MPLS ping' as mentioned in 
> the draft)
> 
> 15) Section 5.5: I think you need to mention that if 
> intermediate LSRs don't support refresh reduction, then it 
> could take many minutes before the echo-reply is received at 
> the source.
> 
> 17) Section 3.2: Why are there multiple downstream labels in 
> the downstream mapping? do they belong to different LSP 
> levels? Or the figure is simply showing many downstream mapping TLVs? 
> 
> 19) Section 4.3: Should an Echo reply always have a 
> downstream mapping TLV even if no downstream mapping TLV is 
> in the Echo request?
> 
> 20) Section 4.4: Seems like back to back echo-request can't 
> be sent before receiving the echo-reply of previous 
> echo-request. Why this limitation?
> 
> 21) Section 5.1: How is the downstream mapping TLV conveyed 
> in the echo-reply sent over RSVP-TE? it seems no downstream 
> mapping TLV is defined for RSVP-TE.
> 
> 
> Thanks,
> -Shahram
> 
>   
>

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Wed, 04 Dec 2002 16:45:53 -0500

Sharam,

I guess this email was for LSP Ping.

JP.

At 13:30 04/12/2002 -0800, Shahram Davari wrote:
>Hi,
>
>Although I have no hope of getting any response, but here is a repeat of 
>my ignored comments raised in March, 2002 and some new ones:
>
>1) Time stamp: Why is the time stamp in both seconds and microseconds? The 
>microsecond could count up to 71 minutes. Isn't that enough? Why isn't the
>2) Section 3: Why the echo reply time stamp is not similar to ICMP 
>echo-reply time-stamp in which a received time-stamp and sent-time stamp 
>is set by the receiver? Which gives you the processing time at the 
>receiver too.
>
>3) Section 3.1: If I understand it correctly a Target FEC TLV could 
>consist of a number of FEC stack sub-TLVs. Therefore it seems that the 
>number of these sub-TLVs could be determined by looking at the Target FEC 
>TLV length field and subtracting the sub-TLV lengths from it. But the text 
>says it could be determined by looking at the sub-TLV length field. Needs 
>clarification.
>
>4) Section 3.1: How can you ping multiple FECs simultaneously (i.e., piggy 
>back multiple pings), while each FEC belongs to a different level of the 
>label stack? This requires that all those hierarchical labels (LSPs) be 
>initiated and terminated at the same LSRs. Also how do you intend to 
>generate error response if the result of some of those FEC pings are 
>5) Section 3 under return code. There is no return code for the case that 
>one of the FECs fail while others pass, or when one of the label mappings 
>don't pass, while others pass.
>
>6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to 
>the same LSP level? It seems that if 1000s of FECs are all mapped to the 
>same LSP, then 1000's of MPLS-pings are required.
>
>7) Why is the downstream label field in the downstream mapping TLV 24 
>bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit?
>
>8) Section 3.2: When X receives a packet with TTL of n>1, shouldn't it 
>compute the downstream LSRs that could receive the packet with TTL=n-1 
>(rather than TTL=n+1 as indicated)?
>
>10) Section 4.3: Does the downstream mapping TLV of the echo-reply replace 
>the downstream mapping TLV of the echo-request or it is appended to it?
>
>11) Section 4.5: If the egress for an FEC stack being pinged doesn't 
>support MPLS ping, isn't an ICMP TTL expire message generated for the IP 
>TTL=1 received (instead of no reply as mentioned in the draft)?
>
>12) Section 5 2nd paragraph last sentence I think should be changed to: 
>"Note that this may not work if some transit LSR does not support IP 
>options" (not 'MPLS ping' as mentioned in the draft)
>
>15) Section 5.5: I think you need to mention that if intermediate LSRs 
>don't support refresh reduction, then it could take many minutes before 
>the echo-reply is received at the source.
>
>17) Section 3.2: Why are there multiple downstream labels in the 
>downstream mapping? do they belong to different LSP levels? Or the figure 
>is simply showing many downstream mapping TLVs?
>
>19) Section 4.3: Should an Echo reply always have a downstream mapping TLV 
>even if no downstream mapping TLV is in the Echo request?
>
>20) Section 4.4: Seems like back to back echo-request can't be sent before 
>receiving the echo-reply of previous echo-request. Why this limitation?
>
>21) Section 5.1: How is the downstream mapping TLV conveyed in the 
>echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is 
>defined for RSVP-TE.
>
>
>Thanks,
>-Shahram
>
>
>

---

From: Ling Li <[email-masked]>
Date: Thu, 12 Dec 2002 20:23:56 -0500

The following are my comments and questions on the draft. Your
clarifications are appreciated. --Ling

1. The assumptions made in the draft:
	1). From Section 7: 
	"Therefore, an LSR which is on the path
	of a protected LSP SHOULD always assume that it is a merge point"

	2). From Section 8:
	"if a DETOUR object is included in the backup LSP's path
	message for the sender-template-specific method, the LSRs in the
      traffic-engineered network should support the DETOUR object.

   	Second, if the Path-Specific Method is to be supported for
      the one-to-one backup technique, it is necessary that the LSRs in
      the traffic-engineered network be capable of merging detours "

These are very important assumptions. Could these assumptions be mentioned
in the 
Introduction section to avoid confusion when reading the first several
sections?
For example, the hop-limit constraint in Section 4.1 is very confusing
without
assumption 1).

Questions: 
1. Is the following assumption implied by the draft:
an LSR which is on the path of a protected LSP SHOULD always assume that 
it is a PLR.

Without this assumption, the NHOP or NNHop bypass may not work as expected.
That is because NHOP bypass can only protect a downstream neighbor link. If
the downstream neighbor node is not a PLR, a failure of the remote
downstream
link is going to be propagated to the current node. If the current node
knows
that its downstream neighbor is not a PLR, it may use NNHop to protect the 
neighbor node and the remote downstream links. Since the current node has no
way
to know if the downstream neighbor is PLR, I guess it is assumed.

2. I think the following statements in Section 4.2 is not needed because
of assumption 2).
"LSRs that do not support the DETOUR objects MUST reject any Path message 
containing a DETOUR object and send a PathErr to notify the PLR."
If really needed, please provide Error Code and Value. Hard to imagine
anyone
will upgrade their code for not supporting a feature.

Some general comments:
1. in Section 6.2, "For detour LSPs, the destination MUST be the tail-end of
the protected LSP". However the hop-limit constraint is "from current node
(a PLR) 
to a MP". It is not easy to enhance cspf to support this constraint if 
it is defined this way. I would prefer not setting constraint to MP, but to
the destination, such as what is de	fined in Juniper product:
"For fast reroute, how many more routers a detour is allowed to traverse
compared 
to the LSP itself" at
http://www.juniper.net/techpubs/software/junos52/swconfig52-
mpls-apps/html/mpls-summary18.html#1014333.

2. The following statement is not very clear in Section 5:
"If node protection is desired, the head-end LSR should set the "node
protection desired" flag in the SESSION_ATTRIBUTE object; if only link
protection is desired, this flag should be cleared. " 
Could it be changed to use Otherwise after the first half of the statement,
jus as
what is said for "bandwidth protection desired" flag after the statement. 

3. The following statement is made is Section 6:
"  If the "node protection desired" flag is set, the PLR SHOULD try to
   provide node protection; if this is not feasible, the PLR SHOULD
   then try to provide link protection."
Can we say the same for "bandwidth protection desired" flag? 
"  If the "bandwidth protection desired" flag is set, the PLR SHOULD try to
   provide bandwidth protection; if this is not feasible, the PLR SHOULD
   set the bandwidth constraint to 0 then try to provide protection."