RE: MRN ext. doc

["PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>]

hi adrian 

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

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
> Sent: Friday, October 31, 2008 12:40 AM
> To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
> Subject: Re: MRN ext. doc
> 
> 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.

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

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

> ===
> References need updating. idnits should help you.
> ===
> Section 4 refers to section 8.2 of RFC 4206. Should be 6.2?

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

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

TE domain is defined as group of LSRs that enforces a common TE policy. 
> 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.

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.
> ===
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- 
> From: "PAPADIMITRIOU Dimitri" 
> <Dimitri.Papadimitriou@alcatel-lucent.be>
> To: <ccamp@ops.ietf.org>
> Sent: Monday, October 27, 2008 8:04 AM
> Subject: MRN ext. doc
> 
> 
> folks -
> 
> before asking for LC, we plan an update of this doc. see:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ml
> n-extensio
> ns-02.txt>
> 
> please let us know if you see any missing description/holes in this
> version (beside its IANA section).
> 
> thx,
> -d.
> 
> 
>