Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-lite-03

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 1 Jun 2011 13:39:16 +0200

Hi Paco, all,

Sorry for the delay - I just posted a revised version (-04) which includes the changes on MPLS VPN encapsulation discussed. (3GPP also recently updated 3GPP 23.975 and added MPLS VPN encapsulation, already leveraging the clarifications provided by the discussion below)

Regards, Frank

> -----Original Message-----
> From: Paco Cortes [mailto:[email-masked]]
> Sent: Monday, April 11, 2011 11:35 AM
> To: Frank Brockners (fbrockne)
> Cc: [email-masked]
> Subject: Re: draft-ietf-softwire-gateway-init-ds-lite-03
> 
> Hi Frank,
> 
> fine with me. It is better than my original proposal.
> 
> br,
>   Paco
> 
> 2011/4/11 Frank Brockners (fbrockne) <[email-masked]>:
> > Hi Paco,
> >
> > thanks - and I agree with you that the description of the MPLS VPN
> > variant is currently ambiguous and needs refinement. I agree
> > with your suggested changes. One additional thought: Given that the
> > SWID for MPLS VPNs can really be "something" which uniquely
> identifies
> > the VPN, how about making the SWID at both ends of the softwire a
> > completely generic identifier, with the one quality of uniquely
> > identifying the VPN? We'd give the two embodiments you mention
> > as examples, but wouldn't restrict things to just the two. For
> > MPLS VPNs the SWID isn't really something which requires
> specification,
> > hence we can leave it to the implementers to pick something
> > appropriate.
> >
> > Here's a proposal for a slightly modified SECOND CHANGE:
> >
> > o MPLS VPN: The SWID is a generic identifier which uniquely
> identifies
> > the VPN at either the Gateway or AFTR. Depending on whether the
> Gateway
> > or AFTR are acting as CE or PE, the SWID could e.g. be an attachment
> > circuit identifier, an identifier representing the set of VPN route
> > labels pointing to the routes within the VPN, etc. The AD's
> > IPv4-address is the CID. For a given VPN, the AD's IPv4 address must
> > be unique.
> >
> > Thanks, Frank
> >
> >
> >> -----Original Message-----
> >> From: Paco Cortes [mailto:[email-masked]]
> >> Sent: Saturday, April 09, 2011 2:20 PM
> >> To: [email-masked]; Frank Brockners (fbrockne)
> >> Subject: draft-ietf-softwire-gateway-init-ds-lite-03
> >>
> >> Hi all,
> >>
> >> When reading the description of the MPLS VPN variant of GI-DS-lite,
> my
> >> interpretation has always been that the gateway and the AFTR are
> >> connected to the MPLS VPN [RFC4364] as CE devices.
> >> In an off-line discussion with Frank, we realized that we had
> >> different interpretations and that his intention had been to
> describe
> >> both nodes as PE devices.
> >> We then realized that the I-D is ambiguous, allowing both
> >> interpretations, and we also agreed on that both of them are
> actually
> >> sound possible implementations, as well as the combination of them
> >> (i.e. the gateways acting as CE and the AFTR as PE, or the other way
> >> around).
> >>
> >> With this email I'd like to propose some small updates to the draft
> in
> >> order to explicitly mention these possibilities, as well as to
> correct
> >> other minor statements which I found confusing or misleading while
> >> trying to read more deeply the MPLS VPN embodiement description.
> >>
> >> VPN-ID is mentioned as SWID for the MPLS VPN case, without
> specifying
> >> what the VPN-ID might be. It could be interpreted as the identifier
> of
> >> an attachment circuit (if the Gateway or AFTR are CEs), a VRF-wide
> >> MPLS label if an implementation uses it, or some other internal VRF
> >> identifier, for instance an associated route distinguisher, if an
> >> implementations uses route specific MPLS VPN route labels.
> >> The term "MPLS VPN label" is used once, which is
> ambiguous/confusing.
> >> A generic use of RFC 4364 would imply that this is a set of MPLS VPN
> >> route labels which match routes within one VPN. Only an
> implementation
> >> choosing a single MPLS label for an entire VRF (one of the
> >> alternatives in RFC 4364 section 4.3.2) could correctly used the
> >> singular form. But I doubt that it is the intention of this I-D to
> >> mandate a specific implementation of RFC 4364.
> >> I also think that if the gateway and the AFTR are acting as PEs,
>  the
> >> fact that the MPLS labels used by them are not the same deserves
> >> explicit mention. I.e., that "the SWID does not need to be globally
> >> unique, i.e. different SWIDs could be used to identify a softwire at
> >> the different ends of a tunnel". (quoting Frank)
> >>
> >> So, here are my proposed changes to draft-ietf-softwire-gateway-
> init-
> >> ds-lite-03:
> >>
> >> FIRST CHANGE
> >> In section 3 of the I-D I would extend the sentence:
> >> "The softwire is identified by a softwire identifier (SWID)"
> >> to say
> >> "The softwire is identified by a softwire identifier (SWID), which
> >> does not need to be globally unique, i.e. different SWIDs could be
> >> used to identify a softwire at the different ends of a softwire"
> >>
> >> SECOND CHANGE
> >> In section 6 of the I-D, I would modify the bullet:
> >> "   o  MPLS VPN: SWID is the MPLS VPN label.  The AD's IPv4-address
> is
> >>       the CID.  For a given MPLS VPN label, the AD's IPv4 address
> must
> >>       be unique."
> >> to say
> >> "o MPLS VPN: depending on the gateway or the AFTR being connected as
> >> CE or PE devices, the SWID is respectively an attachment circuit
> >> identifier or a representation of the VPN route labels pointing to
> >> routes within the VPN. The AD's IPv4-address is the CID. For a given
> >> VPN, the AD's IPv4 address must be unique"
> >>
> >> THIRD CHANGE
> >> RFC 4364 should be added as reference.
> >>
> >> END OF PROPOSED CHANGES
> >>
> >> I didn't see the need for other changes.
> >> On the one hand, the draft could benefit from more details on the
> >> different cases (combinations of CEs and PEs) and advantages or
> >> disadvantages. On the other hand, the draft does not go into any of
> >> the implementations (GRE, IPv4 in IPv4, ...) in details, so that
> >> adding more on the MPLS VPN variant could create an unbalance.
> >>
> >> I'm also aware that it can be discussed if it is correct to say that
> a
> >> gateway or AFTR acts as PE device, or if we should say that they act
> >> as combined CE+PE devices. But I personally prefer the first wording
> >> ;-).
> >>
> >> Any opinions?
> >>
> >> br,
> >>   Paco
> >