[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MRN ext. doc
adrian
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Friday, October 31, 2008 11:16 AM
> To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
> Subject: Re: MRN ext. doc
>
> 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. ...
ok - you would like a ref. to 5339.
> >> ===
> >> 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.
can u please use the ietf terminology at least to make the point
understandable to me (excuse my ignorance). what is a mapped server ?
> >> ===
> >> 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].
yes, they "complement" is that not the definition of an extension ?
> >> ===
> >> 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.
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.
> 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?
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
> >> ===
> >> 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
where do you see the "duplication" of information b/w IACD and ISCD ?
thanks,
-d.
> what happens
> if the bandwidth cited in the IACD is greater than that in
> the ISCD? etc.
>
> Cheers,
> Adrian
>
>