The MPLS WG Archive

["Roberto Mameli (TEI)" <Roberto.Mameli@tei.ericsson.se>]

Hello all,
 
I have some observations on draft-ietf-mpls-rsvp-lsp-tunnel-0.8. I have gone through the mailing list but I've not been able to find comments on it. So here is a list of my observations. Sorry in advance for the length of this message. I also apologize if some of my questions are straightforward and have been discussed yet.
 
1) Quoted from the beginning of section1.1: "Hosts and routers that support both RSVP and MPLS...".
Please correct me if I'm wrong, but even if not explicitly stated elsewhere, my understanding about MPLS was that this framework was to be employed within the network (I mean NOT on user hosts). Am I missing something about that?
 
2) There should be a typo in sec. 2.2, at the beginning of page 11: "If a Path message is allowed to progress when there are insufficient resources, the there is a danger... ". I think "the" should be changed in "then". More generally, what does this statement stand for? It seems that upon the reception of a Path message the LSR should trigger an Admission Control decision (see also par. 4.7.3 - page 50: "When a Path message is considered for admission... "). As far as I know in the ordinary RSVP processing Admission Control is performed upon Resv reception, according to the receiver initiated approach. Is this changed in the RSVP-TE extension? If so, is admission performed on the basis of the Tspec value? What about writing it more explicitly elsewhere?
 
3) Sec. 2.3 (page 12) and par. 2.6 (page 15) refers to section 4.8, but there is no sec. 4.8 in the draft
 
4) Sec. 2.3 again refers to Class-of-Service service. I've never heard about it, any info/pointer/clarification?
 
5) Sec. 2.4 at the beginning states: "The receiver node can select from among...". "from" should be deleted
 
6) Sec. 4.2 at the beginning states: "The Label Request Class is 19. Currently there three...". "are" is missing between "... there three...".
 
7) Sec. 4.2 page 25. "... if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages...". The canonical way by which a RSVP router knows about a non-RSVP neighbor is by means of the TTL field in the common header of the RSVP message. This value is set equal to the IP TTL by the sender and decremented by every RSVP node along the path, while the IP TTL is decremented by every node along the path. In this way, if an RSVP router observes that the 2 TTL values are different, then it assumes that UPSTREAM there is at least a non-RSVP router. Now, the point is that a router can determine if the UPSTREAM node is non-RSVP capable, but as far I know it has no means to know if the DOWNSTREAM node is non-RSVP capable. Assuming this lack of knowledge about the DOWNSTREAM node I wonder how it can decide not to advertise the LABEL_REQUEST object DOWNSTREAM. Is some form of static configuration required?
 
8) Quoted from the beginning of page 28: "The path between a loose node and its preceding node MAY include other network nodes that are not part of the STRICT node or its preceding abstract node". Should "STRICT" in the sentence be substituted by loose?
 
9) In the description of IPv4 prefix and IPv6 prefix subobjs (sections 4.3.3.2 and 4.3.3.3) the Resvd field is called Padding in the description. I think it would be better to use of the same terminology in both the figure and the description below.
 
10) Referring to section 4.7.4 it seems to me that there are conflicting sentences. Specifically what happens if a link cannot be validated because one of the three tests reported is not passed? Page 51 reports: "If the test fails a PathErr with the code "Policy Control Failure" SHOULD be sent", while page 52 states:"If the test fails, the node SHOULD send a PathErr message with an error code of "Routing Problem" and ....". . Did I misunderstand something?
 
Thanks for your kind attention!
 
Best regards
Roberto

application/ms-tnef