RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Dimitri

The text you quote was put in the architecture/ framework, not to
exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which
has been there for many years and may be in use. 

Perhaps the working needs to be adjusted but I don't think it is a major
issue.

Regards,
Don 

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri
> Sent: Tuesday, January 22, 2008 4:16 PM
> To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> 
> All,
> 
> > We received a couple of comments in the meeting, we would 
> > appreciate additional feedback on the list.
> 
> The document states:
> 
> "The L2SC Interface Switching Capabilities MUST NOT be used 
> to represent
> interfaces capable of supporting Eth-LSPs. Interface Switching
> Capability specific TE information may be defined as needed to support
> the requirements of a specific Ethernet Switching Service Type."
> 
> [...]
> 
> "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."
> 
> This is explicit statement that GMPLS per RFC 3945 is not applicable.
> So, it is much more than just an additional codepoint, as the control
> plane behaviour is to be defined for this codepoint. So, it 
> is the open
> door for a new control plane behaviour. 
> 
> so, let's have a more basic questioning before jumping into the single
> alternative resulting from this doc.:
> 
> - either it is GMPLS for Ethernet architecture and then what exist in
> current RFCs should be applicable (because i do not see any rationale
> for L2SC def. departure for Ethernet frame processing);
> 
> - or not it is X for Y architecture, where X is an IP control protocol
> based some potentially on some existing GMPLS blocks and Y is not
> compatible with the existing definition of Eth frame processing.
> 
> In the latter case, i do not know how this WG can deal with such case
> (from the control plane perspective).
> 
> -d.
> 
> 
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org 
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, 
> > DEBORAH A, ATTLABS
> > Sent: Tuesday, January 22, 2008 8:28 PM
> > To: ccamp@ops.ietf.org
> > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > 
> > CCAMP,
> >  
> > The DT proposed in their meeting presentation for their 
> > architecture and framework document to be accepted as a WG draft:
> > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> >  
> > We received a couple of comments in the meeting, we would 
> > appreciate additional feedback on the list. Please express 
> > your support (or otherwise) for this I-D to become a WG draft.
> >  
> > Thanks,
> > Deborah
> > 
> 
>