Subject: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-01.txt

From: Andreas Ripke <[email-masked]>
Date: Fri, 4 Jul 2014 11:05:22 +0000

Dear all,

Thank you for all the feedback we received at the last meeting on the TUNNEL_ID option. This was very helpful. We have updated our draft accordingly and aligned our use case with use cases from existing PCP drafts/RFCs. Particularly we moved the focus from a rather static web portal scenario to a more dynamic UPnP Interworking scenario. 

http://www.ietf.org/internet-drafts/draft-ripke-pcp-tunnel-id-option-01.txt

Please have a look at the draft and give us your feedback.

Best regards,

Andreas

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

A new version of I-D, draft-ripke-pcp-tunnel-id-option-01.txt
has been successfully submitted by Andreas Ripke and posted to the IETF repository.

Name:		draft-ripke-pcp-tunnel-id-option
Revision:	01
Title:		PCP Tunnel-ID Option
Document date:	2014-07-03
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-ripke-pcp-tunnel-id-option-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ripke-pcp-tunnel-id-option/
Htmlized:       http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-option-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ripke-pcp-tunnel-id-option-01

Abstract:
   This document describes a new Port Control Protocol (PCP) option
   called TUNNEL_ID.  It serves for identifying a Third Party in
   addition to the means that PCP's THIRD_PARTY option already provides
   for that purpose.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 08:42:29 +0000

Hi Andreas,

Thank you for sharing this updated version of the document. 

I'm not sure about the carrier-hosted IWF because one of the motivations for PCP to avoid overloading the carrier network with a chatty protocol. 

FWIW, I have identified in this document as case that require an identification information that cannot be included in a THIRD_PARTY option:
http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-00 
"   o  Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC
      address), an opaque subscriber-identifier, an IMSI, etc."

I suggest you change TUNNEL_ID to something that won't mislead the reader that a tunneling technique is always in place when this option is in use.

Cheers,
Med

>-----Message d'origine-----
>De : pcp [mailto:[email-masked]] De la part de Andreas Ripke
>Envoyé : vendredi 4 juillet 2014 13:05
>À : [email-masked]
>Objet : [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-
>option-01.txt
>
>Dear all,
>
>Thank you for all the feedback we received at the last meeting on the
>TUNNEL_ID option. This was very helpful. We have updated our draft
>accordingly and aligned our use case with use cases from existing PCP
>drafts/RFCs. Particularly we moved the focus from a rather static web
>portal scenario to a more dynamic UPnP Interworking scenario.
>
>NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End
>Road, London, HA4 6QE, GB | Registered in England 2832014
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Andreas Ripke <[email-masked]>
Date: Wed, 9 Jul 2014 10:02:23 +0000

Hi Med,

Thanks for your comments.

Our scenario is a supplement to situations when PCP is not yet on hand in the subscriber realm.
The carrier IWF is offered as a service to the subscribers.
It does not prevent subscribers to directly use PCP to control ports on the CGN.

And thanks for your pointer to your pcp-sfc draft.
It looks like the PCP TUNNEL_ID option aligns to this direction of an extension proposal.

The decision we called the new option TUNNEL_ID was driven by the given scenario.
Yes, it might be an idea to change and generalize the option name to ID instead of TUNNEL_ID.

Best,

Andreas

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2014 10:42 AM
> To: Andreas Ripke; [email-masked]
> Subject: RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
> 01.txt
> 
> Hi Andreas,
> 
> I'm not sure about the carrier-hosted IWF because one of the motivations
> for PCP to avoid overloading the carrier network with a chatty protocol.
> 
> FWIW, I have identified in this document as case that require an
> identification information that cannot be included in a THIRD_PARTY option:
> I suggest you change TUNNEL_ID to something that won't mislead the
> reader that a tunneling technique is always in place when this option is in
> use.
> 
> Cheers,
> Med
> 
> >Envoyé : vendredi 4 juillet 2014 13:05 À : [email-masked] Objet : [pcp]
> >FW: New Version Notification for draft-ripke-pcp-tunnel-id-
> >option-01.txt
> >
> >Dear all,
> >
> >NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West
> >End Road, London, HA4 6QE, GB | Registered in England 2832014
> >
> >
> >
> >
> >
> >

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 14:27:09 +0000

Re-,

Please see inline.

Cheers,
Med

>De : Andreas Ripke [mailto:[email-masked]]
>Envoyé : mercredi 9 juillet 2014 12:02
>À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
>Objet : RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
>01.txt
>
>Hi Med,
>

[Med] But how the CPE will decide to leak UPnP IGD outside the LAN? Shouldn't this require an upgrade of the CPE to support some "kind" of UPnP IGD relay? 

>Yes, it might be an idea to change and generalize the option name to ID

[Med] Great! 

>> >URL:            http://www.ietf.org/internet-drafts/draft-ripke-pcp-
>tunnel-
>> >id-option-01.txt
>> >Status:         https://datatracker.ietf.org/doc/draft-ripke-pcp-tunnel-
>id-
>> >option/
>> >Diff:           http://www.ietf.org/rfcdiff?url2=draft-ripke-pcp-tunnel-
>id-
>> >option-01
>> >
>> >Abstract:

---

From: Andreas Ripke <[email-masked]>
Date: Fri, 11 Jul 2014 14:41:57 +0000

Hi Med,

Thanks for the hint on UPnP relay. This might not be necessary.
Apparently, we have to describe the scenario in more detail.

Best,

Andreas

> Sent: Wednesday, July 09, 2014 4:27 PM
> >De : Andreas Ripke [mailto:[email-masked]] Envoyé : mercredi 9
> >juillet 2014 12:02 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet :
> >RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
> >01.txt
> >
> >Hi Med,
> >
> [Med] But how the CPE will decide to leak UPnP IGD outside the LAN?
> Shouldn't this require an upgrade of the CPE to support some "kind" of UPnP
> IGD relay?
> 
> >
> >> I'm not sure about the carrier-hosted IWF because one of the
> >> motivations for PCP to avoid overloading the carrier network with a
> chatty protocol.
> >>
> >> reader that a tunneling technique is always in place when this option
> >> is
> >in
> >> use.
> >>
> >> Cheers,
> >> Med
> >>
> >> >Thank you for all the feedback we received at the last meeting on
> >> >the TUNNEL_ID option. This was very helpful. We have updated our
> >> >draft accordingly and aligned our use case with use cases from
> >> >existing PCP drafts/RFCs. Particularly we moved the focus from a
> >> >rather static web portal scenario to a more dynamic UPnP Interworking
> scenario.
> >> >
> >> >http://www.ietf.org/internet-drafts/draft-ripke-pcp-tunnel-id-option
> >> >-01
> >> >.txt
> >> >
> >> >NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> >> >West End Road, London, HA4 6QE, GB | Registered in England 2832014
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 14:45:27 +0000

Hi Andreas,

I'm curious to see how this can work with legacy CPEs.

Looking forward to reading an updated version of the draft.

Cheers,
Med

>Envoyé : vendredi 11 juillet 2014 16:42

---

From: RAFAEL ALEJANDRO LOPEZ DA SILVA <[email-masked]>
Date: Fri, 11 Jul 2014 15:00:18 +0000

Hi Med:

Thank you for your suggestions, and as Andreas says we will have to describe better the scenario in a next version.

Just as an advance though on the options for the UPnP IGD-PCP IWF. Some operators are deploying layer 2 CPEs, while moving some layer 3 CPE functionalities to the network. With that you are extending the Layer 2 domain of the Home LAN into the ISP network. One of the Layer 3 CPE functionalities shifted to the network could be the UPnP IGD to PCP IWF, for allowing devices without PCP support request dynamic mappings to a CGN. To achieve scalability this IWF could be located off-path (even though with Layer 2 visibility of the Home devices) and use a mediation system to signal the mappings to the CGN on its behalf using the Tunnel Id option.

That is achievable with legacy CPEs in bridge mode.

Best
Rafael López da Silva

-----Mensaje original-----
De: pcp [mailto:[email-masked]] En nombre de [email-masked]
Enviado el: viernes, 11 de julio de 2014 16:45
Para: Andreas Ripke; [email-masked]
Asunto: Re: [pcp] New Version Notification for draft-ripke-pcp-tunnel-id-option-01.txt

Hi Andreas,

Cheers,
Med

>De : Andreas Ripke [mailto:[email-masked]] Envoyé : vendredi
>11 juillet 2014 16:42 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet
>: RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
>01.txt
>
>Hi Med,
>
>> >De : Andreas Ripke [mailto:[email-masked]] Envoyé :
>> >mercredi 9 juillet 2014 12:02 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet :
>> Shouldn't this require an upgrade of the CPE to support some "kind"
>> of
>UPnP
>> IGD relay?
>>
>> >
>> >> Subject: RE: New Version Notification for
>> >> draft-ripke-pcp-tunnel-id-
>> >option-
>> >> 01.txt
>> >>
>> >> Hi Andreas,
>> >>
>> >> identification information that cannot be included in a
>> >> THIRD_PARTY
>> >option:
>> >> http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-cont
>> >> rol-
>00
>> >> reader that a tunneling technique is always in place when this
>> >> option is
>> >in
>> >> use.
>> >>
>> >> Cheers,
>> >> Med
>> >>
>> >> >De : pcp [mailto:[email-masked]] De la part de Andreas
>> >> >Ripke Envoyé : vendredi 4 juillet 2014 13:05 À : [email-masked] Objet :
>> >> >[pcp]
>> >> >NEC Europe Ltd | Registered Office: Athene, Odyssey Business
>> >> >Park, West End Road, London, HA4 6QE, GB | Registered in England
>> >> >2832014
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 15:11:58 +0000

Hi Rafael,

Thank you for the clarification. 

But given that a legacy CPE, even in the bridge mode, does not leak UPnP IGD messages in the WAN interface, I guess an upgrade is still needed to relax that?

BTW, are you aware of tests that have been conducted to confirm this behavior (I'm talking about the UPnP IGD leg)?

Thank you.

Cheers,
Med

>De : RAFAEL ALEJANDRO LOPEZ DA SILVA
>[mailto:[email-masked]]
>Envoyé : vendredi 11 juillet 2014 17:00
>À : BOUCADAIR Mohamed IMT/OLN; Andreas Ripke; [email-masked]
>Thank you for your suggestions, and as Andreas says we will have to
>describe better the scenario in a next version.
>
>Just as an advance though on the options for the UPnP IGD-PCP IWF. Some
>operators are deploying layer 2 CPEs, while moving some layer 3 CPE
>functionalities to the network. With that you are extending the Layer 2
>domain of the Home LAN into the ISP network. One of the Layer 3 CPE
>functionalities shifted to the network could be the UPnP IGD to PCP IWF,
>for allowing devices without PCP support request dynamic mappings to a CGN.
>To achieve scalability this IWF could be located off-path (even though with
>Layer 2 visibility of the Home devices) and use a mediation system to
>signal the mappings to the CGN on its behalf using the Tunnel Id option.
>
>>> >> >Htmlized:       http://tools.ietf.org/html/draft-ripke-pcp-tunnel-
>id-
>>> >> >option-01
>Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
>puede contener información privilegiada o confidencial y es para uso
>exclusivo de la persona o entidad de destino. Si no es usted. el
>destinatario indicado, queda notificado de que la lectura, utilización,
>divulgación y/o copia sin autorización puede estar prohibida en virtud de
>la legislación vigente. Si ha recibido este mensaje por error, le rogamos
>que nos lo comunique inmediatamente por esta misma vía y proceda a su
>destrucción.
>
>The information contained in this transmission is privileged and
>confidential information intended only for the use of the individual or
>entity named above. If the reader of this message is not the intended
>recipient, you are hereby notified that any dissemination, distribution or
>copying of this communication is strictly prohibited. If you have received
>this transmission in error, do not read it. Please immediately reply to the
>sender that you have received this communication in error and then delete
>it.
>
>Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
>pode conter informação privilegiada ou confidencial e é para uso exclusivo
>da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
>indicado, fica notificado de que a leitura, utilização, divulgação e/ou
>cópia sem autorização pode estar proibida em virtude da legislação vigente.
>Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
>imediatamente por esta mesma via e proceda a sua destruição

---

From: RAFAEL ALEJANDRO LOPEZ DA SILVA <[email-masked]>
Date: Fri, 11 Jul 2014 15:17:48 +0000

Hi Med,

Well then it seems that it may be dependent on the specific vendor/model, because I can assure that some do leak the UPnP IGD messages to the WAN in bridge mode.

And in any case, it isn't a functionality that with a firmware update could not be supported in a legacy CPE (even though it would make the migration to the model more complex)

Regards
Rafael

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]]
Enviado el: viernes, 11 de julio de 2014 17:12
Para: RAFAEL ALEJANDRO LOPEZ DA SILVA; Andreas Ripke; [email-masked]
Asunto: RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-01.txt

Hi Rafael,

Thank you.

Cheers,
Med

>Envoyé : vendredi 11 juillet 2014 17:00 À : BOUCADAIR Mohamed IMT/OLN;
>Andreas Ripke; [email-masked] Objet : RE: New Version Notification for
>draft-ripke-pcp-tunnel-id-option-
>01.txt
>
>Hi Med:
>
>functionalities shifted to the network could be the UPnP IGD to PCP
>IWF, for allowing devices without PCP support request dynamic mappings to a CGN.
>To achieve scalability this IWF could be located off-path (even though
>with Layer 2 visibility of the Home devices) and use a mediation system
>to signal the mappings to the CGN on its behalf using the Tunnel Id option.
>
>De: pcp [mailto:[email-masked]] En nombre de
>[email-masked] Enviado el: viernes, 11 de julio de 2014
>16:45
>Asunto: Re: [pcp] New Version Notification for
>draft-ripke-pcp-tunnel-id- option-01.txt
>
>Hi Andreas,
>
>>> >> I suggest you change TUNNEL_ID to something that won't mislead
>>> >> the reader that a tunneling technique is always in place when
>>> >> this option is
>>> >in
>>> >> use.
>>> >>
>>> >> Cheers,
>>> >> Med
>>> >>
>>> >> >Ripke Envoyé : vendredi 4 juillet 2014 13:05 À : [email-masked]
>>> >> >Objet
>:
>>> >> >[pcp]
>>> >> >Thank you for all the feedback we received at the last meeting
>>> >> >on the TUNNEL_ID option. This was very helpful. We have updated
>>> >> >our draft accordingly and aligned our use case with use cases
>>> >> >from existing PCP drafts/RFCs. Particularly we moved the focus
>>> >> >from a rather static web portal scenario to a more dynamic UPnP
>>> >> >Interworking
>>> scenario.
>>> >> >
>>> >> >http://www.ietf.org/internet-drafts/draft-ripke-pcp-tunnel-id-op
>>> >> >t
>>> >> >ion
>>> >> >-01
>>> >> >.txt
>>> >> >
>>> >> >Please note that it may take a couple of minutes from the time
>>> >> >of submission until the htmlized version and diff are available
>>> >> >at tools.ietf.org.
>>> >> >
>>> >> >The IETF Secretariat
>>> >> >
>Este mensaje y sus adjuntos se dirigen exclusivamente a su
>destinatario, puede contener información privilegiada o confidencial y
>es para uso exclusivo de la persona o entidad de destino. Si no es
>usted. el destinatario indicado, queda notificado de que la lectura,
>utilización, divulgación y/o copia sin autorización puede estar
>prohibida en virtud de la legislación vigente. Si ha recibido este
>mensaje por error, le rogamos que nos lo comunique inmediatamente por
>esta misma vía y proceda a su destrucción.
>
>recipient, you are hereby notified that any dissemination, distribution
>or copying of this communication is strictly prohibited. If you have
>received this transmission in error, do not read it. Please immediately
>reply to the sender that you have received this communication in error
>and then delete it.
>
>Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>destinatário, pode conter informação privilegiada ou confidencial e é
>para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
>senhoria o destinatário indicado, fica notificado de que a leitura,
>utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente.

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Jul 2014 09:03:52 +0300

> But given that a legacy CPE, even in the bridge mode, does not leak UPnP IGD messages in the WAN interface, I guess an upgrade is still needed to relax that?

If it’s in ~L2 bridging mode, and doesn’t do anything clever (such as bridge-firewalling), why would it not leak UPnP messages on WAN? 

I have CPEs that basically convert media from X to Y (notably, ethernet-ish to something {A,V}DSL-ish), and when they’re in L2 bridging mode, what you stick in from ethernet port, goes on the line, without any clever bits working. If they’re _not_ in bridged mode, all sorts of obvious things happen such as NAT, hop count handling, etc, which would obviously do bad things to UPnP traffic destined to WAN port.

I doubt that any CPE that is _not_ in L2 bridging mode would work with this CGN-side IGD scheme out of the box (given some configuration, yes, but not otherwise).

Cheers,

-Markus

P.S. I consider L2 CPEs good _for advanced users_ and not that great idea as a default. However, I’m sure this draft has it’s place, somewhere.. ;)