[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Thanks Dimitri,
You asked a question below...which I have extracted/inserted below for
ease of reference:
> The
> co-ps mode has the richest scope for 'variation' in the DP
> labelling of
> traffic units (this is more than simply a destination proxy label
> BTW....this was a point I saw Adrian alluding to)....and one can even
> violate the rules of connections here and really screw-up any
> notion of deterministic resource management anyway.
does that imply change in the def. of L2SC as defined in RFC 3945 ? or
is it an add-on that is not impacting other RFC's mechanisms ? my
understanding is the latter but never got an answer whether or not this
is indeed the case (and proposal on how to spell this in the doc.)
NH=> I assume you are referring to the definition of a connection (wrt
to what L2Sc really means)? A connection can only have a single source
and it must not re-order traffic units...a subtle corollary of this is
that a connection can only have a single traffic/QoS class. This means
connections can only be p2p or p2mp in construction. This is a
necessary requirement for resource assignment determinism. Assuming one
does not violate these rules (and you can't in the co-cs mode) then
there is no need to include a SA label in the traffic units of a
connection....the parent connection object carries that semantic.
Further, because a connection represents a chosen set of link
connections (hops) between the source and the sink(s)then:
- in the case of a p2p connection the label carrying the DA
information need only be link connection unique (across the population
of clients served by the lower layer network connection on that link),
ie it can be swapped hop by hop
- in the case of a p2mp connection the label carrying the DA is a
'name' (proxy) that respresents a set of real DAs.
These labelling short-cuts is all works fine until there are
misconnectivity defects. But if one wants to make the network more
robust to such defects (without even using any adjunct OAM flows at all)
then including the SA in each traffic unit and not-swapping the DA in
the case of p2p connections (ie just use the real DA and not a proxy for
it) has many benefits. Now if you start with a traffic unit that was
originally designed for cl-ps operation and use it for a co-ps operation
then the above labelling information is already present, ie one has no
need to take short-cuts on removing the SA or making the DA only link
connection unique....the cl-ps mode cannot allow such short-cuts as
there is no connection that provides this information.
Now if one chooses to create mp2p merging constructs and there is also
no SA information then you have lost information on where the traffic
unit came from.....and this lost information must be provided by some
other means (usually an appeal to a higher layer entity => which if
cl-ps (eg IP) allows SA recovery directly or if not cl-ps (eg ATM, etc)
requires a further label is added to provide this information, eg PW
label in MPLS). But this is only dealing with the loss of SA
information caused by merging....we still have the issue that merging
constructs cannot have deterministic resource allocation.
I'm not sure that answers your question, because it assumes the above is
understood (implicit?) in the definition of what L2SC really means....I
suspect the above considerations have not really been taken into
account.
regards, Neil
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
> Sent: 30 January 2008 23:40
> To: Harrison,N,Neil,DMF R; howard.green@ericsson.com; loa@pi.se
> Cc: Niven-jenkins,B,Ben,DMF R; lberger@labn.net;
> dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>
>
>
> neil,
>
> > -----Original Message-----
> > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > Sent: Wednesday, January 30, 2008 7:14 PM
> > To: PAPADIMITRIOU Dimitri; howard.green@ericsson.com; loa@pi.se
> > Cc: benjamin.niven-jenkins@bt.com; lberger@labn.net;
> > dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >
> > I personally think you are making a mountain out of a molehill here
> > Dimitri.
>
> the segmentation of SCs we have in RFC 3945 is sufficient to
> address your below decomposition. you have to consider that
> when a new techno is to be supported by GMPLS, stacks are not
> going to change the full engine/stack per specific technology -
>
> > And I thought I had explained why there are differences in the
> > treatment of layer networks depending on their mode...I
> clearly did a
> > bad job.
>
> don't worry, we very well understand the difference between a
> circuit-switched and packet-switched network.
>
> > Sure GMPLS is a generic OOB CP suite of protocols, but the
> details of
> > the parameters used used to describe the layer network being
> > considered will depend on:
> > - for the co-cs mode whether we are dealing with resources which
> > are either regular time-slices, freq or space
> > - for the co-ps mode there is only irregular time-slices.
>
> L2SC is in the latter.
>
> > And the labelling of such resource partitions is different in
> > each case
> > too...so just like it is impossible to have a common (ie
> > single instance
> > of) CP running 'IP to Optics' (or any functional component for that
> > matter) it is impossible to have an identical set of parameters
> > describing each mode....this is just the physics and the way
> > it is. The
> > co-ps mode has the richest scope for 'variation' in the DP
> > labelling of
> > traffic units (this is more than simply a destination proxy label
> > BTW....this was a point I saw Adrian alluding to)....and
> one can even
> > violate the rules of connections here and really screw-up any
> > notion of deterministic resource management anyway.
>
> does that imply change in the def. of L2SC as defined in RFC
> 3945 ? or is it an add-on that is not impacting other RFC's
> mechanisms ? my understanding is the latter but never got an
> answer whether or not this is indeed the case (and proposal
> on how to spell this in the doc.)
>
> the addition to adrian's text is a way out. it is to be
> followed by discussions because the protocol aspects remain open.
>
> thanks,
> -d.
>
> > regards, Neil
> >
> > > -----Original Message-----
> > > From: PAPADIMITRIOU Dimitri
> > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
> > > Sent: 30 January 2008 17:23
> > > To: Howard Green; Loa Andersson
> > > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;
> > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;
> > > ccamp@ops.ietf.org
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Howard Green [mailto:howard.green@ericsson.com]
> > > > Sent: Wednesday, January 30, 2008 12:09 PM
> > > > To: PAPADIMITRIOU Dimitri; Loa Andersson
> > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;
> > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;
> > > > ccamp@ops.ietf.org
> > > > Subject: RE: Proposed WG Draft -
> draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > Hi
> > > > Dimitri seems to me to be making a very abstract and
> > > legalistic point.
> > >
> > > receive my total disagreement. an individual submission that
> > > asks to change an existing RFC requires discussion and
> > > particular attention (in part., when it is the protocol arch.
> > > document) - if this not possible then probably you have to
> > > write also a doc. asking for changing the IETF proces - and
> > > then you come back with your individual submission.
> > >
> > > > The reason why this work is important is that the IEEE has been
> > > > evolving Ethernet to give it carrier class features, in
> respect of
> > > scalability,
> > > > OAM, and (with 802.1Qay) the possibility to use an
> > external control
> > > > plane.
> > >
> > > no one i think question this. and i don't think the poll is
> > > on this specific point. CCAMP or even IETF at large is not an
> > > authority to decide upon IEEE technos.
> > >
> > > > Some of these features will very likely require or enable
> > > added value
> > > > from extensions to the functionality of GMPLS - for
> > example, as has
> > > > already been suggested, the addition of functionality
> > for creating
> > > > the OAM associations.
> > >
> > > indeed, and your colleague has already received a list of
> > > comments to be addressed before seeing any way forward w/ the
> > > proposed approach.
> > >
> > > > Therefore this will likely not be the same as the possible use
> > > > suggested in RFC3945, which may (at least in theory) have been
> > > > implemented somewhere.
> > >
> > > the exact problem, i mentionned a couple of times. your own
> > > comment shows that one may use GMPLS differently but may i
> > > ask WHY ? and what's the implications ?
> > >
> > > > Therefore the suggestion in the draft seems to make sense.
> > >
> > > why ?
> > >
> > > > I can't really see what important principle is being
> defended by
> > > > the insistence upon L2SC, which, as Don Fedyk
> > > stated, was
> > > > always somewhat underspecified.
> > >
> > > THE reason is that an interface SC or a related functionality
> > > has never resulted in a specific change in the base protocol
> > > building blocks. GMPLS is a generalized approach not a
> > > differentiated approach per interface.
> > >
> > > actually your last statement is not correct (L2SC is well
> > > specified in RFC 3945) AND by the way yours does not at all
> > > better specify it.
> > >
> > > > This is not something to be debated in the abstract. The
> > > work in ccamp
> > > > should allow sensible extension of functionality where it
> > > adds value,
> > > > and this needs to be discussed on a case by case basis.
> > > Therefore we
> > > > should make it a working group document and get on with it.
> > >
> > > -d.
> > > > regards Howard Green
> > > >
> > > > -----Original Message-----
> > > > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On
> > > > Behalf Of PAPADIMITRIOU Dimitri
> > > > Sent: 30 January 2008 10:15
> > > > To: Loa Andersson
> > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;
> > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;
> > > > ccamp@ops.ietf.org
> > > > Subject: RE: Proposed WG Draft -
> draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > loa,
> > > >
> > > >
> > > > i think the main point as ccamp is whether or not we poll
> > > for a change
> > > > or a continuation inline with RFC3945 -- when the present
> > > doc. states:
> > > >
> > > > "It is expected that there will be no
> > > > case where an Eth-LSP will be signaled, or an Eth-LSP
> > supporting
> > > > interface will be represented, using the L2SC switching
> > > > type/capability. A new switching type/capability is
> > required to
> > > > avoid any potential current usage of the L2SC switching
> > > > type/capability in support of Ethernet.
> > > >
> > > > [...]
> > > >
> > > > "The L2SC Interface Switching Capabilities MUST
> > > > NOT be used to represent interfaces capable of supporting
> > > > Eth-LSPs."
> > > >
> > > > it raises three issues:
> > > >
> > > > a) what was the previous L2SC def. per RFC 3945 meant
> for if not
> > > > for use also in GMPLS Ethernet context ?
> > > >
> > > > b) why a "new one" ?
> > > >
> > > > this is not explained.
> > > >
> > > > c) what is the "new one" implying in terms of GMPLS ?
> > > >
> > > > for inst. in the intro "The intent of this document is to
> > reuse and
> > > > align with as much of the GMPLS protocols as possible."
> > leaves open
> > > > the issue of what as much as possible means.
> > > >
> > > > and on the other "Additions are made only to accommodate
> > > features of
> > > > Ethernet that are not already supported by GMPLS." so,
> > how shall i
> > > > interpreet the first sentence now ? inline with point
> a) and b) ?
> > > >
> > > >
> > > > the doc. in WG I-D status or not is not going to provide an
> > > answer to
> > > > these questions. sentences and statements in the doc.
> > > contradict each
> > > > other.
> > > >
> > > > thanks,
> > > > -d.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Loa Andersson [mailto:loa@pi.se]
> > > > > Sent: Tuesday, January 29, 2008 2:04 PM
> > > > > To: PAPADIMITRIOU Dimitri
> > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;
> > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;
> > > > > ccamp@ops.ietf.org
> > > > > Subject: Re: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > > >
> > > > > Dimitri,
> > > > >
> > > > > it is possible that you have a point that needs to be
> > > > discussed, but
> > > > > is this really something that should stop us from adopting
> > > > the doc as
> > > > > a working group document.
> > > > >
> > > > > /Loa
> > > > >
> > > > > PAPADIMITRIOU Dimitri wrote:
> > > > > > neil,
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: neil.2.harrison@bt.com
> [mailto:neil.2.harrison@bt.com]
> > > > > >> Sent: Friday, January 25, 2008 2:27 PM
> > > > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;
> > > > > >> lberger@labn.net
> > > > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com;
> ccamp@ops.ietf.org
> > > > > >> Subject: RE: Proposed WG Draft -
> > > draft-gmpls-ethernet-arch-00.txt
> > > > > >>
> > > > > >> Dimitri....see if this helps...in-line
> > > > > >>
> > > > > >>> -----Original Message-----
> > > > > >>> From: owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org]
> > > > > >>> On Behalf Of
> > > > > PAPADIMITRIOU Dimitri
> > > > > >>> Sent: 25 January 2008 11:36
> > > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> > > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > ccamp@ops.ietf.org
> > > > > >>> Subject: RE: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > >>>
> > > > > >>>
> > > > > >>> ben
> > > > > >>>
> > > > > >>>> -----Original Message-----
> > > > > >>>> From: Ben Niven-Jenkins
> > > [mailto:benjamin.niven-jenkins@bt.com]
> > > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM
> > > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger
> > > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > ccamp@ops.ietf.org
> > > > > >>>> Subject: Re: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > >>>>
> > > > > >>>> Dimitri,
> > > > > >>>>
> > > > > >>>> I find your mail somewhat puzzling.
> > > > > >>>>
> > > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set
> > > > > >>> in stone and
> > > > > >>>> nothing should modify/enhance the behaviour as specified
> > > > > >> in RFC3945
> > > > > >>>> which implies that when RFC3945 was produced the crystal
> > > > > ball was
> > > > > >>>> working extremely well and all possible future
> > > > > applications of the
> > > > > >>>> technology had
> > > > > >>>> been correctly envisaged. I don't believe that
> > was the case.
> > > > > >>> this is not what i say. i am concerned in stating
> > > > beforehand RFC
> > > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet.
> > Why the doc.
> > > > > >>> does not deliver any tangible explanation.
> > > > > >> NH=> Is your problem that you cannot differentiate
> > > between the 3
> > > > > >> network modes (of co-cs, co-ps and cl-ps)?
> > > > > >
> > > > > > my concern wrt specific point you bring is that the today
> > > > > definition in
> > > > > > RFC 3945 for L2SC, and in the present case GMPLS for
> > > > Ethernet (with
> > > > > > local labels or domain-wide labels or any other equivalent
> > > > > to "co-ps")
> > > > > > does not result into a different definition than what's in.
> > > > > on the other
> > > > > > side, i do not see how would apply GMPLS for
> > > > connectionless/bridged
> > > > > > Ethernet.
> > > > > >
> > > > > > note also that GMPLS induces label from the
> interface and link
> > > > > > characteristic (i.e. there is no "label type" in the
> > > > > label/label request
> > > > > > object.
> > > > > >
> > > > > >> If so then looking at the work on
> > > > > >> unified modelling in SG15/Q12 may help you. But to
> > give a more
> > > > > >> specific example here: We can take an Ethernet
> > > traffic unit and
> > > > > >> create either a cl-ps and co-ps layer network based on
> > > this...in
> > > > > >> fact one
> > > > > can image 3
> > > > > >> different layer network cases here:
> > > > > >> - traditional Etherent which does not have a
> > > > directed routing
> > > > > >> function, ie uses MAC learning, broadcast unknown,
> > > > STP...this is a
> > > > > >> cl-ps layer network
> > > > > >> - Ethernet with an IGP providing a directed routing
> > > > > >> function....this is also a cl-ps layer network, but it is
> > > > > different to
> > > > > >> the one above
> > > > > >> - Ethernet with a directed routing component
> > > > (centralised or
> > > > > >> distributed, ie IGP) and a signalling component that
> > can create
> > > > > >> connections....this would be a co-ps layer network.
> > > > > >>
> > > > > >> These are all based on a similar traffic unit, however
> > > > they form 3
> > > > > >> quite different layer networks (and in functional
> > architecture
> > > > > >> terms we would say 'the Characteristic Information is
> > > > different in
> > > > > >> the 3 cases').
> > > > > >>
> > > > > >> Now GMPLS is applying a reusable set of CP components
> > > > > (which is a very
> > > > > >> good thing, as Ben points out below) for any co-cs or
> > > > > co-ps mode layer
> > > > > >> network. So we are setting up *connections* in
> > either a space,
> > > > > >> freq or time dimension of resource, and it is these
> > 3 resource
> > > > > dimensions that
> > > > > >> create the differences in parameters...however, the
> > notion of a
> > > > > >> connection is common across all these resource dimensions.
> > > > > GMPLS does
> > > > > >> not apply to the cl-ps mode, as it plainly does not have
> > > > > connections.
> > > > > >
> > > > > > well indeed, and this is the reason why i do not see any
> > > > reason to
> > > > > > open the space for a different set of mechanisms that
> > > > would result
> > > > > > from this new interface switching definition.
> > > > > >
> > > > > > thanks,
> > > > > > -d.
> > > > > >
> > > > > >> That is at least how I look at this issue.
> > > > > >>
> > > > > >> regards, Neil
> > > > > >>>>> the question triggered by this poll is the following: if
> > > > > >>> GMPLS for
> > > > > >>>>> Ethernet is not inline with the existing stacks what is
> > > > > >>> the value of
> > > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS
> > > > > >>> without its
> > > > > >>>>> substance ? and in practice, the issue is, if it is not
> > > > > >>>> GMPLS per RFC
> > > > > >>>>> 3945, what's the value compared to any other
> > native control
> > > > > >>>> stack that
> > > > > >>>>> would be developed at IEEE for inst. for these techno's.
> > > > > >>>> If we ignore the peer model (which is unworkable in
> > > > reality IMO),
> > > >
> > > > > >>>> the value is obvious - significant reuse of
> existing code,
> > > > > >>>> techniques, knowledge, skills, etc.
> > > > > >>>>
> > > > > >>>> So, we should develop the control plane from scratch
> > > > > >>> because Ethernet
> > > > > >>>> requires a few modifications/enhancements (which I
> > > believe are
> > > > > >>>> backwards
> > > > > >>>> compatible) to RFC3945 - that IMO is ridiculous.
> > > > > >>> so you seem to agree with me. departing from RFC 3945
> > > > makes little
> > > >
> > > > > >>> sense. it would have been interesting to see the doc
> > > > delivering a
> > > > > >>> FIT of the GMPLS protocol arch. blocks and, in
> > > > particular, label
> > > > > >>> allocation and distribution for Ethernet.
> > > > > >>>
> > > > > >>> thanks,
> > > > > >>> -dimitri.
> > > > > >>>> Ben
> > > > > >>>>
> > > > > >>>>
> > > > > >>>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Loa Andersson
> > > > >
> > > > > Principal Networking Architect
> > > > > Acreo AB phone: +46 8 632 77 14
> > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64
> > > > > Kista, Sweden email:
> > loa.andersson@acreo.se
> > > > > loa@pi.se
> > > > >
> > > >
> > > >
> > >
> >
>