Subject: MRN ext. doc

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 27 Oct 2008 09:04:51 +0100

folks - 

before asking for LC, we plan an update of this doc. see: 

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensio
ns-02.txt>

please let us know if you see any missing description/holes in this
version (beside its IANA section).

thx,
-d.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 30 Oct 2008 23:40:27 -0000

Hi Dimitri,

A very quick scan of this I-D raises a few points.

===
Section 2 references [GR-TELINK]. Is this intended to be 
draft-ietf-ccamp-mpls-graceful-shutdown-08.txt?
There is nothing in the references section to indicate.
===
Section 8 needs to be resolved
===
It would make sense for section 7 to reference 
draft-ietf-mpls-mpls-and-gmpls-security-framework
===
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.
===
References need updating. idnits should help you.
===
Section 4 refers to section 8.2 of RFC 4206. Should be 6.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?
===
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.
===
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.
===
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.
===
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 think it would be valuable to indicate in the Abstract that this work is 
limited to the application of a single TE domain across multiple regions or 
layers.
Furthermore, in the Introduction where this point is raised, it would be 
helpful to explain the meaning of a "single TE domain." There is a passable 
definition in RFC 5212 section 1.
It would be worth clarifying whether a single TE domain can be served by 
more than one IGP instance. This is hinted at in section 5.7 of RFC 5212.
===

Thanks,
Adrian

----- Original Message ----- 
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 27, 2008 8:04 AM
Subject: MRN ext. doc

folks -

thx,
-d.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 31 Oct 2008 09:37:05 +0100

hi adrian 

thx for the feedback - here below a couple of hints: 

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Friday, October 31, 2008 12:40 AM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Subject: Re: MRN ext. doc
> 
> Hi Dimitri,
> 

yes will add a ref.
> Section 8 needs to be resolved

yes already part of the update
> 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.
> 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 ? 

> Section 4 refers to section 8.2 of RFC 4206. Should be 6.2?

yes. 
> to defer this to Section 5?

i don't understand the question. 
> set up FAs to form virtual TE links although that is clearly 

referenced in section 5.1 ad 5.2 but i added a ref. to RFC4206
> object, you want the Call to fail.

this what has been agreed from last meeting. see Lou's preso.
> soon-to-be-set-up LSP will 

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).

> 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.

> definition in RFC 5212 section 1.

TE domain is defined as group of LSRs that enforces a common TE policy. 
> more than one IGP instance. This is hinted at in section 5.7 

per 5212, we did even not limit it to single AS. for the specific
question you ask wrt IGP, in a sense we bind applicability to IGP
capability not the other way around.

thanks,
-d.
> From: "PAPADIMITRIOU Dimitri" 
> <[email-masked]>
> To: <[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 31 Oct 2008 10:15:53 -0000

Hi,

Thanks.

Closing on a couple of points...

> do you have any specific point not covered by this section and covered

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.

>> traceability such that it is necessary to read most of 5339
>> to ensure that all requirements have been met.
>

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?
>

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.
>

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].

>> Surely if any node that processes the Notify message does not
>> understand the object, you want the Call to fail.
>

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
>
> 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].
>

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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 31 Oct 2008 18:50:42 +0100

adrian 

> Sent: Friday, October 31, 2008 11:16 AM

ok - you would like a ref. to 5339.

> between the two sections 4 and 5.

can u please use the ietf terminology at least to make the point
understandable to me (excuse my ignorance). what is a mapped server ?

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

yes, they "complement" is that not the definition of an extension ?

> is nowhere for the message to be forwarded if the object is 

not sure. at the end the question is an attribute object class a
criteria for which rejection is expected. going one step further one can
mandate support of the class but it is the support of the associated
capability that matters.. one would be still blocking on the latter
anyway if that capability would not be supported independently of the
object class. so it is the "mandatory or optional" nature of the
attribute that induce support of the object not the other way around. 

> Shouldn't the call indicate which server the caller 

assume a base virtual TE link [PSC,PSC] and the two link sequence that
can be followed by the FA-LSP are either [PSC,LSC]..[LSC,LSC]..[LSC,PSC]
or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association between the TE
link and LSP that determines to which FA that TE link is now related to

> Now since there is a an aggregate duplication of information

where do you see the "duplication" of information b/w IACD and ISCD ?  

thanks,
-d.

> what happens