Subject: [Tsvwg] Use of GMPLS [RFC3473] RSVP-TE extensions in draft-ietf-tsvwg-rsvp-proxy-proto-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Sep 2007 23:29:58 +0100

Hi,

My attention has been drawn to draft-ietf-tsvwg-rsvp-proxy-proto-01.txt as 
CCAMP WG co-chair. CCAMP is the Routing Area WG responsible for GMPLS 
extensions to RSVP-TE [RFC3473], and this I-D is proposing the use of 
several of these extensions within core RSVP.

I can see no issue in principle with this usage. The GMPLS RSVP-TE protocol 
extensions are defined as extensions to the base RSVP [RFC2205] definitions 
and use the same IANA registries for messages, objects, etc. It makes good 
sense to re-use protocol mechanisms especially as the RSVP codepoint 
registries are getting crowded.

I haven't fully reviewed the draft in question, but I have looked at the two 
relevant sections. I have some comments as follows:

Section 3.1.3 describes the use of the "Path_State_Removed" flag defined in 
RFC3473 for use in the ERROR_SPEC object's flags field. The RFC observes 
that:
   The semantics of the Path_State_Removed flag are simply that the node
   forwarding the error message has removed the Path state associated
   with the PathErr.
The inference is that a PathErr does not normally cause Path state to be 
removed.
You should be aware, however, that recent work in the MPLS working group has 
exposed the fact that some RSVP-TE implementations for MPLS (i.e., not for 
GMPLS) take a stronger view of a PathErr and do remove Path state without 
the need for the Path_State_Removed flag. You may want to look at 
draft-ietf-mpls-soft-preemption-08.txt (now expired) that exposed the 
problem, and draft-vasseur-mpls-3209-patherr-01.txt (also expired!) that 
tried to qualify the situation.
Since RSVP and RSVP-TE codebases are often common, it may be valuable to 
look closely at the situation for RSVP.

Section 3.1.3 appears to make a change (by omission) to the processing rules 
for the Path_State_Removed flag as compared to RFC3473. You might want to 
think about the situation and consider whether to make the change explicit 
(which would be good for clarity if you intend the difference), or to bring 
your text in line with RFC3473. The issue concerns a transit router that 
receives a PathErr with the Path_State_Removed flag clear, and decides to 
set it in the PathErr that it propagates - RFC3473 says that if this 
happens, the router that sets the flag MUST also send PathTear. 
Alternatively, it may be the case that you intend to prevent any router 
except the proxy receiver from actively setting the flag.

Lastly for section 3.1.3, you suggest that the Path_State_Removed flag "can 
be used in environments where all RSVP routers are known to support the 
Path_State_Removed flag." I would suggest that this knowledge is hard or 
impossible to guarantee and very risky to assume. It may be a good idea to 
examine the behavior if some routers do not recognise/support the flag.
a. The flag will be propagated unchanged so upstream routers
    will get to see it.
b. The legacy router will not remove its Path state and associated
    resources, and will not later receive a PathTear. But it will time
    out the soft-state (or more probably receive a ResvErr the
    next time it sends a Resv refresh).

Section 3.2 describes the use of the Notify message. This appears to be a 
good use of the message, but there are some things you may want to consider.

i. Although the specification of the Notify message says to package it in IP 
addressed to the intended recipient and not the next RSVP hop, and although 
RFC3473 also explicitly states that the router alert option is not used on 
the IP datagram that carries the Notify message, many implementations of 
RSVP intercept IP datagrams based on the protocol identifier. In these 
cases, transit routers are required to know about the Notify message and to 
be able to forward it (unmodified) to its intended destination. Effectively, 
hop-by-hop forwarding needs to be supported.

ii. You will want to consider the trust and security models for Notify 
messages that are sent direct since normal RSVP trust and security is based 
on neighbor relationships.

iii. Figure 4 would benefit from the inclusion of a third "regular RSVP 
router" to show that the Notify is not just traversing a single hop.

iv. It may be helpful to show the PathErr messages on figure 4 as well. 
There are two considerations:
    - The proxy receiver may decide to use the
       Path_State_Removed flag
    - The Notify message in RFC3473 is explicitly
       specified to not replace the PathErr

v. It seems unlikely at the moment, but at some time in the future it is 
possible that the receiver of the Notify message is capable of RSVP (per 
this I-D) and packet-based GMPLS (per RFC3473). In this case, it may be 
valuable to facilitate rapid distinction between Notify messages (recalling 
that the originator of the Notify is not an immediate neighbor, so it is 
hard to know the protocol behavior from the source IP address). It may be 
possible to use the <flow descriptor> on the message to make this 
distinction, but a mechanism that is being used within the GMPLS community 
to distinguish Notify message uses is to include the Admin_Status object and 
designate one of the bits (see RFC4974 section 5.5 for an example). If you 
decide to use this approach, it would be helpful if you would coordinate 
with me to achieve smooth allocation of a bit number.

I hope this helps.

Bottom line - yes, go ahead.

Cheers,
Adrian

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 13 Sep 2007 15:21:42 -0700

Adrian,

Snipped...

>Section 3.2 describes the use of the Notify message. This appears to be

>a good use of the message, but there are some things you may want to 
>consider.
>
>i. Although the specification of the Notify message says to package it 
>in IP addressed to the intended recipient and not the next RSVP hop, 
>and although
>RFC3473 also explicitly states that the router alert option is not used

>on the IP datagram that carries the Notify message, many 
>implementations of RSVP intercept IP datagrams based on the protocol 
>identifier. In these cases, transit routers are required to know about 
>the Notify message and to be able to forward it (unmodified) to its 
>intended destination.
>Effectively, hop-by-hop forwarding needs to be supported.

JD:  Doesn't RFC 3473 mention this in order to accommodate these
aberrant implementations?

>messages that are sent direct since normal RSVP trust and security is 
>based on neighbor relationships.

JD:  Isn't it sufficient to simply say that Notify is used exactly as
described in RFC 3473?

>v. It seems unlikely at the moment, but at some time in the future it 
>is possible that the receiver of the Notify message is capable of RSVP 
>(per this I-D) and packet-based GMPLS (per RFC3473). In this case, it 
>may be valuable to facilitate rapid distinction between Notify messages

>(recalling that the originator of the Notify is not an immediate 
>neighbor, so it is hard to know the protocol behavior from the source 
>IP address). It may be possible to use the <flow descriptor> on the 
>message to make this distinction, but a mechanism that is being used 
>within the GMPLS community to distinguish Notify message uses is to 
>include the Admin_Status object and designate one of the bits (see 
>RFC4974 section 5.5 for an example). If you decide to use this 
>approach, it would be helpful if you would coordinate with me to 
>achieve smooth allocation of a bit number.

JD: What is the utility of this bit?  Is it to indicate that the Notify
refers to a non TE session or that the Notify was sent by an RSVP proxy?
If it is the former, then this I-D isn't the place to define it, since
it might someday be sent in the non-proxy case.

>Bottom line - yes, go ahead.

JD: Yes indeed

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 14 Sep 2007 10:03:59 +0200

Adrian, John,

Thanks for your comments. Thoughts below:

> aberrant implementations?

Regardless, the intent of rsvp-proxy is to use Notify as specified in  
RFC3473.
Since RFC3473 allows multiple methods for forwarding Notify messages,  
those are also assumed as valid by rsvp-proxy.

I propose to add a statement to rsvp-proxy making it explicit that:
	-(a) rsvp-proxy only discusses the additional procedures that are  
specific to the use of Notify in the context of Receiver Proxies
	-(b) beyond these specific procedures, Notify procedures specified  
in RFC3473 do apply

The current text discusses the procedures specific to Receiver Proxy,  
but only implies (b). Making (b) explicit should clarify the point  
above about various forwarding options. BTW, I expect it will also  
clarify a few other things  (including one of the questions raised  
earlier by Dimitri- more on that separately).

> JD:  Isn't it sufficient to simply say that Notify is used exactly as

Right. As mentioned above, we will add such a statement that Notify  
is used as per RFC3473.

I propose to also add a few words in the Security Considerations  
section on Notify:
	- to indicate that security considerations for Notify messages are  
specifically discussed in the Security Considerations section of  
RFC3473 and those apply
	- to mention that the approach already discussed in rsvp-proxy/Sec  
Cons of sharing keys among RSVP routers (to solve the problem of non- 
RSVP-hops) also applies to Notify messages that are NOT forwarded hop- 
by-hop.

>> router" to show that the Notify is not just traversing a single hop.

Agreed. Will do.

>>       specified to not replace the PathErr

We realised that Notify is explicitly specified to not replace the  
error message that triggers it. However, in the scenario illustrated  
in Fig 4, the Notify message is triggered by a ResvErr. Both the  
ResvErr and the Notify are shown in Figure 4 (indeed to show that the  
Notify does not stop the error message from being sent).

> it might someday be sent in the non-proxy case.

I think the RSVP router receiving the Notify can simply look at the  
Session object (inside Notify) to determine whether the Notify  
relates to a GMPLS session or a non-GMPLS session.

>> Bottom line - yes, go ahead.

Great to hear support from CCAMP experts.

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 14 Sep 2007 12:09:51 +0200

Hi Adrian,

On 13 Sep 2007, at 00:29, Adrian Farrel wrote:

> Hi,
>
> My attention has been drawn to draft-ietf-tsvwg-rsvp-proxy- 
> proto-01.txt as CCAMP WG co-chair. CCAMP is the Routing Area WG  
> responsible for GMPLS extensions to RSVP-TE [RFC3473], and this I-D  
> is proposing the use of several of these extensions within core RSVP.
>
> I can see no issue in principle with this usage. The GMPLS RSVP-TE  
> protocol extensions are defined as extensions to the base RSVP  
> [RFC2205] definitions and use the same IANA registries for  
> messages, objects, etc. It makes good sense to re-use protocol  
> mechanisms especially as the RSVP codepoint registries are getting  
> crowded.

Good.

>
> I haven't fully reviewed the draft in question, but I have looked  
> at the two relevant sections. I have some comments as follows:
>
> Section 3.1.3 describes the use of the "Path_State_Removed" flag  
> defined in RFC3473 for use in the ERROR_SPEC object's flags field.  
> The RFC observes that:
> The inference is that a PathErr does not normally cause Path state  
> to be removed.
> You should be aware, however, that recent work in the MPLS working  
> group has exposed the fact that some RSVP-TE implementations for  
> MPLS (i.e., not for GMPLS) take a stronger view of a PathErr and do  
> remove Path state without the need for the Path_State_Removed flag.  
> You may want to look at draft-ietf-mpls-soft-preemption-08.txt (now  
> expired) that exposed the problem, and draft-vasseur-mpls-3209- 
> patherr-01.txt (also expired!) that tried to qualify the situation.
> Since RSVP and RSVP-TE codebases are often common, it may be  
> valuable to look closely at the situation for RSVP.

Noted.
That seems to be more of a generic considerations for RSVP than an  
rsvp-proxy specific consideration, though.
rsvp-proxy discusses the case where the PSR flag is used. The case  
where the PSR flag is not used is not discussed by rsvp-proxy and  
assumed to work as per regular RSVP.

>
> Section 3.1.3 appears to make a change (by omission) to the  
> processing rules for the Path_State_Removed flag as compared to  
> RFC3473. You might want to think about the situation and consider  
> whether to make the change explicit (which would be good for  
> clarity if you intend the difference), or to bring your text in  
> line with RFC3473. The issue concerns a transit router that  
> receives a PathErr with the Path_State_Removed flag clear, and  
> decides to set it in the PathErr that it propagates - RFC3473 says  
> that if this happens, the router that sets the flag MUST also send  
> PathTear. Alternatively, it may be the case that you intend to  
> prevent any router except the proxy receiver from actively setting  
> the flag.

We don't intend to change the rules of RFC3473 on intermediate  
routers. And in particular we don't intend to explicitely prevent an  
intermediate router from setting the flag (if there is a good reason  
for it to do so). It sounds like it would help if we add a statement  
to the effect that "beyond the specific statements we make on use of  
PSR flag in the context of Receiver Proxies, the procedures of 3473  
pertaining to PSR still apply".

>
> Lastly for section 3.1.3, you suggest that the Path_State_Removed  
> flag "can be used in environments where all RSVP routers are known  
> to support the Path_State_Removed flag." I would suggest that this  
> knowledge is hard or impossible to guarantee and very risky to  
> assume. It may be a good idea to examine the behavior if some  
> routers do not recognise/support the flag.

We considered the exact scenario you describe above. And in that  
case, the net result is that the removal of path state will take  
longer and probably involve more signaling than if we were not using  
the PSR flag at all (while the motivation for using PSR was precisely  
to expedite removal and reduce signaling). This is what motivated us to:
	- not use PSR by default
	- suggest that it can be used when all routers are known to be PSR  
capable (note that we don't prevent it from being used when this  
knowledge cannot be guaranteed).

But you're right that we just cannot always assume the knowledge, so  
we need to describe what happens in the scenario above involving a  
non-PSR-capable router. Then we can make clear that in that situation  
you endup worse off than if you did't use the PSR flag (but still  
nothing really breaks since it will time out). That way one can make  
an informed decision on whether they should activate use of PSR or  
not on Proxy.

Thanks

Francois