Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-packet-pw-01.txt

From: Stewart Bryant <[email-masked]>
Date: Tue, 20 Dec 2011 21:56:40 +0000

Lizhong

Thank you for your LC comments

On 07/09/2011 16:35, Lizhong Jin wrote:
> Hi authors,
> If the PE provides active&standby packet PW, then will the two PW be 
> configured with same unicast Ethernet addresses (PacketPWEthA and 
> PacketPWEthB), or different? If different, what kind of unicast 
> Ethernet addresses could be used?
My assumption is that it is the same Ethernet address. The Ethernet 
address is part of the client LSR, and thus if the PW changes you would 
expect that to no be effected by the change in the PW.

However that does beg a question of whether the client LSR is going to 
be able to cope with multiple logical Ethernet interfaces that all use 
the same Ethernet address (which is the current design). If that is a 
problem, then we need to change the design to use real Ethernet 
addresses, and then we are going to hit a number of IEEE issues with the 
number of virtual Ethernet addresses we are going to need to assign to PEs.

> And, I think section 1&4 needs to be revised since virtual ethernet 
> approach is selected, see below.
> Section 1, Introduction
>    Where the client LSR and server PE is co-located in the same
>    equipment, the data-link layer can be simplified to a simple protocol
>    identifier (PID) that is used to multiplex the various data-link
>    types onto a pseudowire.
> [Lizhong] the PID concept is for PID label approach, not virtual 
> ethernet approach.
Yes - I missed that, have changed this to:

"Where the client LSR and server PE is co-located in the same equipment, 
the data-link layer can be simplified to a point to point Ethernet used 
to multiplex the various data-link types onto a pseudowire. This is the 
method that described in this document."
>  Section 4, Forwarding Model
> This LSR determines the next hop in the client
>    layer, and pushes the label needed by the next hop in the client
>    layer.  It then passes the packet to the correct PW instance
>    indicating the packet protocol type.  If the PW is configured to
>    require a CW this is pushed.  The PW instance then examines the
>    protocol type and pushes a label that identifies the protocol type...
> [Lizhong] The procedure defined above seems to be the PID label 
> approach, not virtual ethernet approach.
>
Yes, again you are correct.

Here is the text I propose:

OLD

    This LSR determines the next hop in the client
    layer, and pushes the label needed by the next hop in the client
    layer.  It then passes the packet to the correct PW instance
    indicating the packet protocol type.  If the PW is configured to
    require a CW this is pushed.  The PW instance then examines the
    protocol type and pushes a label that identifies the protocol type to
    the egress PE.  The PW instance then proceeds as it would for a layer
    two PW, by pushing the PW label and then handing the packet to the
    server layer LSR for delivery.  At egress, the packet again arrives
    with the PW label at the top of stack which causes the packet to be
    passed to the correct PW instance.  This PW instance knows that the
    PW type is a packet PW, and hence that it needs to interpret the next
    label as a protocol type identifier.  If necessary the CW is then
    popped and processed.  The packet is then passed to the egress client
    LSR together with information that identifies the packet protocol
    type.  The egress client LSR then forwards the packet in the normal
    manner for a protocol of that type.

NEW

    The client LSR determines the next hop in the
    client layer, and pushes the label needed by the next hop in the
    client layer.  It then encapsulates the packet in an Ethernet header
    setting the Ethertype to MPLS.  The client LSR then passes the packet
    to the correct PW instance.  The PW instance then proceeds as defined
    for an Ethernet PW [RFC4448] by optionally pushing the control word,
    then pushing the PW label, and finally handing the packet to the
    server layer LSR for delivery to the egress PE in the server layer.

    At the egress PE in the server layer, the packet is first processed
    by the server LSR which uses the PW label to pass the packet to the
    correct PW instance.  This PW instance processed the packet as
    described in RFC4448.  The resultant Ethernet encapsulated client
    packet is then passed to the egress client LSR which then processes
    the packet in the normal manner.

END

We (as a WG) are going to have to take a look at the terms
"ingress" and "egress". I complained that the P2MP authors
used ingress and egress, and not the RFC3985 terms, and
I see that we (I) have used ingress and egress here. We
may have to write a note somewhere equating the formal
terms in RFC3985 with the "natural" terms ingress and
egress that most people prefer to use.

I have uploaded -02 of the draft.

- Stewart
(Writing as duty editor of the draft)

---

From: Lizhong Jin <[email-masked]>
Date: Wed, 21 Dec 2011 23:48:10 +0800

Hi Stewart,
Thank you for the reply. I am OK with the changes. Other comments, see
inline.

Lizhong

2011/12/21 Stewart Bryant <[email-masked]>

> PacketPWEthB), or different? If different, what kind of unicast Ethernet
> addresses could be used?
>
> However that does beg a question of whether the client LSR is going to be
> able to cope with multiple logical Ethernet interfaces that all use the
> same Ethernet address (which is the current design). If that is a problem,
> then we need to change the design to use real Ethernet addresses, and then
> we are going to hit a number of IEEE issues with the number of virtual
> Ethernet addresses we are going to need to assign to PEs.
>
[Lizhong] to my knowledge, for point-to-point Ethernet interface, it is
possible for them to share one MAC address.

> [Lizhong] the PID concept is for PID label approach, not virtual ethernet
> approach.
>
> the data-link layer can be simplified to a point to point Ethernet used to
> multiplex the various data-link types onto a pseudowire. This is the method
> that described in this document."
>
>
> [Lizhong] The procedure defined above seems to be the PID label approach,
> not virtual ethernet approach.
>
> END We (as a WG) are going to have to take a look at the terms "ingress"
> and "egress". I complained that the P2MP authors used ingress and egress,
> and not the RFC3985 terms, and I see that we (I) have used ingress and
> egress here. We may have to write a note somewhere equating the formal
> terms in RFC3985 with the "natural" terms ingress and egress that most
> people prefer to use. I have uploaded -02 of the draft. - Stewart (Writing
> as duty editor of the draft)
>
>