Re: MRN ext. doc

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

Hi,

Thanks.

Closing on a couple of points...

> > It would make sense for section 7 to reference
> > draft-ietf-mpls-mpls-and-gmpls-security-framework
>
> do you have any specific point not covered by this section and covered
> by the above ref.

The IESG has repeatedly shown itself to be nervous about the security 
considerations of MPLS and GMPLS networks. Rather than be forced to 
reproduce a lot of material through a series of exchanges during IESG review 
and a sequence of updates to the draft at that stage, it seems pragmatic to 
include a reference to the general analysis of MPLS and GMPLS security.

> > ===
> > We will definitely (well, very probably) be asked if we can show
> > traceability back to the requirements. In fact, RFC 5339
> > includes section
> > 4.1 that gives traceability from the evaluation back to the
> > requirements.
> > Section 2 of this document does not quite give the same level of
> > traceability such that it is necessary to read most of 5339
> > to ensure that all requirements have been met.
>
> the current doc. covers the "delta" in terms of mechanism. so, do you
> mean that mechanisms not requiring any extensions shall also be
> included/described in this document ?

Nope.
Simply that the I-D should explicitly call out the lacunae identified in RFC 
5339.
For example, you could say...
The following features are identified in [RFC5339] as requiring protocol 
extensions:
1. Feature to do something. See Section 1.2.3 of [RFC5339]
2. ...

> > ===
> > Section 4 appears to consider only the mapped server model
> > (allowing a many to one mapping), but not the multiplexed
> > server model. Is it the intention to defer this to Section 5?
>
> i don't understand the question.

Hmm. I'm using ITU terminology.
Mapped server has a connection set up in the server layer "on demand" with 
only the bandwidth required by the client layer connection.
Many-to-one mapped server allows that the server connection set up for a 
previous client layer connection may have "spare" bandwidth that can be 
allocated ("on demand") to support a further client layer connection.
Multiplexed server model causes the "spare" bandwidth to be advertised in 
the client layer as a link.

My question was trying to understand how the required function was split 
between the two sections 4 and 5.

> > ===
> > Section 5 does not include reference to
> > draft-ietf-ccamp-lsp-hierarchy-bis even though this is mentioned
> > in RFC 5339. Shouldn't it?
> > Actually, there is no mention in section 5 of using RFC 4206
> > procedures to set up FAs to form virtual TE links although that is
> > clearly intended in 4206.
>
> referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206

I don't see any reference to draft-ietf-ccamp-lsp-hierarchy-bis in 5.1 or 
5.2.

Section 5.1 "relies on extensions to the GMPLS RSVP-TE Call procedure" so is 
not the same as the 4206 procedure.

Section 5.2 is the "Soft FA approach" and although this could be achieved 
with modifications to the 4206 procedures, it is not the main purpose of the 
4206 procedures.

Perhaps the point is that *this* I-D is only providing additional functions 
not already described in other documents. If so, you can cover this whole 
point with a reminder at the top of section 5...
  This section describes additional features for the support of
  virtual TE links. The procedures described here complement
  those defined in [RFC4206] and [HIER-BIS].

> > ===
> > The Call-Attributes object C-Num is picked from the 11bbbbbb
> > class. Why?
> > Surely if any node that processes the Notify message does not
> > understand the object, you want the Call to fail.
>
> this what has been agreed from last meeting. see Lou's preso.

Well, it's wrong!  :-)

It doesn't make sense to use 11bbbbbb.
Consider that you are using a Notify message that is targetted. Therefore, 
the first node to process the Notify message is the intended end point of 
the call, or a deliberate transit call controller. That means that we 
require the recipient to be able to process the object. Furthermore, there 
is nowhere for the message to be forwarded if the object is not understood.

The special case of a Notify that is forwarded hop-by-hop does not require 
that the Call-Attributes object is processed since transit nodes "just 
forward the Notify message to the target node" without looking at the 
contents.

We should use 0bbbbbbb

> > ===
> > I'm puzzled that the Call described in section 5.1 does not
> > indicate to the intended LSP egress in which layer or
> > region the soon-to-be-set-up LSP will be required to
> > operate.
>
> because
>
> - it is the FA setup that indicates to which bearer the virtual
> link will be associated not the other way around
>
> - the virtual association is used by upper-region LSP so the virtual
> link itself is an abstraction of the bearer/network (in other terms -
> and by definition - one does not create Virtual TE links over Virtual
> TE links)
>
> the only condition which can be verified from the TEDB is that both
> ends of the bearer belongs to the same LSP region (symmetry).

I meant...
Suppose the head and tail of the planned virtual TE link are present in 
three regions (or layers, don't forget layers). One is the client, and two 
are potential servers.
Shouldn't the call indicate which server the caller wishes/intends to use?

> > ===
> > I don't find section 3.2.1 clear on the co-existence within
> > the Link TLV of the IACD sub-TLV and the ISCD sub-
> > TLV [RFC4203].
>
> i will add a statement IACD does not modify format/messaging and
> processing associated to the ISCD.

Thanks.

Now since there is a an aggregate duplication of information, what happens 
if the bandwidth cited in the IACD is greater than that in the ISCD? etc.

Cheers,
Adrian