RE: Layer 2 Switching Caps LSPs

[Dimitri.Papadimitriou@alcatel.be]

sharam,

first thanks for translating a physical interface as PHY+MAC (not port
please read the mail here below) it really helps understanding each other
:-( (knowing that PHY is an acronym for PHYsical)

now the basic issue, GMPLS allows setting up L2SC LSPs using Ethernet as
LSP encoding type and L2SC as switching type i.e. through - ditto RFC 3945
- "Interfaces that recognize frame/cell boundaries and can switch data
based on the content of the frame/cell header." (examples provided after
this sentence are simply illustrative) where from this definition do you
see a restriction from having an LSP processing the set of incoming frames
processing the VLAN_ID (which is afaik is part of the frame header) as a
way to seggregate flows crossing a port - which thus appear as a refinment
of the port mode

therefore, why applying this definition (coming from an RFC - the GMPLS
architecture - of the CCAMP WG) as part of other documents of the same WG
would not be not possible ?

concerning the question "do we need to detail the exact data plane
processing as part of this document to obtain an interoperable definition",
the response is complex because

o) if both vendor 1 and vendor 2 claims support for L2 LSPs - for the
backward compatible case i already responded to you - having three devices
in a row with the following sequence vendor_1 - vendor_2 - vendor_1, you
can not preclude the intermediate device to not do bridging/ learning,
(don't forget there is no insertion of any new field or any modification in
the frame header) even if it does not provide any functionality in the
point- to-point context we are discussing here, while this operation is
opaque to the operation of its neighboring devices as vendor_1 that would
apply link local semantic and vendor_2 a network wide one;

o) on the other side assuming the edge devices vendor is mandating bridging
at the data plane this is also opaque to the way (a sequence of)
intermediate devices will perform local frame forwarding, lastly such
device (vendor_2) taking the - so i do not see what i should deliver more
in terms of data plane processing as part of this document as
interoperability is ensured;

also the question on using bridging (here we speak about local frame
processing) is subtle in this context because a device claiming support of
L2 LSP may still apply it but (in the point-to- point context we are
discussing here) it does not play a role because the path for these frames
are known during the LSP establishment; therefore there is no mandatory
application of MAC learning/ bridging but note that this document does not
refer to these nodes as .1d bridges to avoid any confusion (as similarly in
the PW WG one does not refer to a PE as a bridge);

so what's left in fact very little, probably that as it is the already case
in the port mode, accept that the establishment of the LSP itself
determines the external behaviour of the forwarding operations performed by
the node (however, note that as it is the case in any other standard there
is no need to specify the exact implementation of the forwarding/switching/
connection function) and ensure a "per-port" based VLAN interpretation (but
i don't see today what would preclude implementing this)

---

Dimitri,

By Physical interface Ben means A single port (PHY +MAC). It is like a
single TCP/IP port. You need another STANDARD function not defined in 802.3
to do the forwarding. AFAIK IEEE defines 802.1D for such function. Do you
have any other Standard Forwarding function that this draft is targeting?

-Shahram

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Dimitri.Papadimitriou@alcatel.be
> Sent: Friday, February 04, 2005 2:26 PM
> To: Mack-Crane, T. Benjamin
> Cc: Dimitri.Papadimitriou@alcatel.be; Shahram Davari;
> dpapadimitriou@psg.com; David Allan; Adrian Farrel; ccamp@ops.ietf.org
> Subject: RE: Layer 2 Switching Caps LSPs
>
>
>
> ben,
>
> > As I think Sharam has noted, 1) is a physical interface.
>
> i don't understand what you mean by 1) (= Ethernet 802.3) is
> a "physical
> interface" please take a look at IEEE 802.3 to see that it defines the
>
> 1.4.167 Media Access Control (MAC): The data link sublayer that is
> responsible for transferring data to and from the Physical Layer.
>
> - as also depicted in Figure 2.1 and 2.2, where you will see
> that PHY is
> just below the MAC sub-layer but the latter is not the "PHY"
> - Fig 2.1 is
> rather explicit
>
>
>