-----Original Message-----
From: Adrian Farrel [SMTP:AF@dataconnection.com]
Sent: Monday, October 23, 2000 2:11 PM
To: mpls@UU.NET
Cc: lberger@labn.net; Ashwood-Smith, Peter [CAR:CS0I:EXCH]
Subject: draft-ietf-mpls-generalized-signaling-00.txt
Lou and Peter,
Thanks for a great job editing this and for getting it out into the public
domain.
I have a large block of comments and questions and bunch of minor typos.
Please feel free to split the comments into separate threads if you like.
Regards,
Adrian
Questions
=========
Link Id and Explicit Routing
I'm not sure how much this should be in Kireeti's bundling draft
and how much in the Generalized draft. I have the following
concern:
- Suppose we use LSR addresses (i.e. not link addresses) in our
explicit route and also use label sub-objects. Suppose further
that there are multiple links of different types between a pair
of LSRs. Finally consider that Label_Request is used, not
Generalized_Label_Request.
How does the LSR processing the ERO interpret the label and
decide which link to apply it to?
I guess you could say that you should avoid the combination of
circumstances listed above and use G_L_R to constrain the link
type or use the link address not the LSR address. Does that
still work with unnumbered links?
Error values etc.
Can I suggest adding a section at the end as a place holder for new error
values.
In the text I have found
- Routing Problem/Unsupported Encoding
- Routing Problem/Unsupported Link Protection
- Routing Problem/Unsupported GPID
- Routing Problem/Unacceptable Label Value
- Routing Problem/Label Set
3. Generalized Label Request
Could you make it clearer right at the top of section 3 that
for RSVP the Generalized_Label_Request is not a new object but a
new variant of the Label_Request Object, whereas for CR-LDP it is
a new TLV.
3.3.1 Waveband Switching
"For compatibility reasons, a new RSVP c-type and CR-
LDP type is assigned for the Waveband Label."
This seems to be the only place in the draft where you
haven't explicitly suggested values (subject to IANA).
I think you have left gaps for RSVP c-type 3 and CR-LDP
type 903.
3.5.1 Label Set
It isn't clear how a sequence of subchannels that form a
label set are conveyed. It can't be the case that you
simply add multiple Subchannels to the Object/TLV since
the Type is closely associated with each individual
Subchannel.
We should either define Label_Set as Explicit_Route with
a sequence of subobjects. Or we should allow a series
of Label_Sets in the Path/LABEL_REQUEST.
In either case, it would be good to put in some motherhood
about ordering the elements for clear interpretation. For
example, suppose x<y<z. Can I define the label set
{x, x+1, ... , y-1, y+1, ..., z} using three subchannels
(viz. start x, exclude y, end z) or must I use four?
3.5.2 Label_Set Procedures
I suppose it is implicit, but there is no mention of inserting
Label_Set for the first time.
4. Bidirectional LSPs
I think it would help to point out that the support for
bidirectional LSPs added here is restricted to certain levels
of symmetry
- the TSpec is the same in both directions
- the LSRs on the path are the same in both directions
- the links between LSRs are not necessarily the same in both
directions.
Suggested_Label
Sorry if I missed this.
Must Suggested_Label be chosen from within the Label_Set?
4.2 Bidirectional LSP Procedures
The choice you have made is consistent (that you may not
propagate a Path containing Upstream_Label until the local
switch has been programmed, so that the terminator may start
sending data as soon as it has processed the Path) but may
unnecessarily increase the latency of LSP set up (compare
with the arguments for Suggested_Label).
If ResvConf were to be requested and used, the individual
switch programming tasks could be processed in parallel with
the propagation of the Path message. The terminator is not
allowed to start sending data until it receives the ResvConf.
This is a direct trade-off, but could quite easily reduce
setup time for individual LSPs.
4.3 Bidirectional LSP Contention Resolution
Note that action on receipt of a PathErr is in contradiction
with RFC2205. This is, however, the correct function in the
situation described.
4.3 Bidirectional LSP Contention Resolution
The suggested behavior for reducing contention depends on
adjacent LSRs knowing each other's node IDs. Does this
rely on Hello messages, carnal knowledge or what?
5. Notification
Flag this at the top as being RSVP only.
5.1.2 Notify Request Procedures
We should add a statement about multiple instances of this object.
The current discussion allows just a single instance.
5.2.2 Notify Procedures
This version of the text does not prohibit the Notify Node from
being other than the requester (i.e. initiator or terminator).
We should either impose this for the time being, or note that
the Notify Node might not support Notify messages (and so will
not send an Ack).
5.2.2 Notify Procedures
It's not clear to me that the default time of 1ms for combining
Notifies is relevant.
5.3 Removing State with PathErr
Note that the reference to RFC 2205 here is obsoleted by the
actions required for bidriectional LSPs (see 4.3) and by
processing that may be utilized for local repair and fast
re-route.
In effect, RFC 2205's rules for forwarding PathErr without
taking action have are already bent.
5.3 Removing State with PathErr
Can we add some text describing the Path state on downstream
nodes when Path_State_Removed is used. If I receive PathErr
w/o P_S_R, am I allowed to remove Path state and send PathErr
w/ P_S_R?
6.2 Procedures
The text listing the errors could do with some cleaning.
The L-bit isn't the only issue here. The nature of the previous
sub-object can be strict but imprecise (i.e. a non-unitary
abstract node .. prefix != 32) or could be an Autonomous System
number. In CR-LDP, the subobject could be an LSPId.
Reporting explicit labels.
draft-ietf-mpls-rsvp-lsp-tunnel-07 has scope in the RRO for
reporting labels, but this doesn't quite match the ERO extensions
here. In particular we need
- scope for two label objects per hop
- definition of the U bit
I believe that this should be in a new section 6.3
Specifying links in EROs
I know we discussed this a bit before, but I want to check that
we're in synch.
We're allowing the IP address subobject in an explicit route to
identify an egress link rather than a next hop. It becomes a
local matter how such subobjects are handled.
We are not allowing specification of a link _and_ a next hop. This
rules out parallel links in a multidrop network.
We do not have the ability to specify an unnumbered link. This is
seen as illogical since the indexes of unnumbered links have only
local (and possibly extending to the other end of the link) meaning.
BNFs
Label_Set is optional
Trivial typos (haven't I got better things to do?)
=============
page 4 for "ends on a LSC" read "ends on an LSC"
page 5 for "traditional and and non-PSC" read "traditional and non-PSC"
page 6 for "come from non-PSC" read "comes from non-PSC"
page 7 for "as specific a LSP Encoding Type" read "as specific an LSP
Encoding Type"
3.2.1.1 for "SDH and SONET define each" read "SDH and SONET each define"
3.2.1.1 for "directly the distinction" read "the direct distinction"
3.2.1.1 for "take part into the inverse" read "take part in the inverse"
3.2.1.1 for "higher order signal need to be" read "higher order signal needs
to be"
3.2.1.1 for "in the increasing order" read "in increasing order"
3.5 for "there are a sequence" read "there is a sequence"
4.3 for "since the label sets are exchanged" read "if the label sets are
exchanged"
5.1.2 Notify Target Object should be Notify Request Object (twice)
5.2 for "who's" read "whose"
5.2 "Notify Ack" is obsolete, read "Ack"
5.3 for "receiving such a error" read "receiving such an error"
6. for "This occurs case when" read "This occurs in the case when"
9. strike "Non-adjacent bundle messages, and"
10. rsvp-lsp-tunnel is up to version 7 now.
--
Adrian Farrel mailto:af@dataconnection.com
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422