[pcp] PCP in Service Provider Networks - (was Re: Comments on draft-cheshire-pcp-recovery-02)

[Reinaldo Penno <[e-mail]>]

Hello,

Separation of subscriber management interfaces from NAT/PCP and use VRFs are
common practice in CGN deployments.

Such deployments and strategy are discussed in multiple draft related to
IPv4/IPv6 co-existence and transition. A few references.

http://tools.ietf.org/html/draft-kuarsingh-lsn-deployment-05
http://tools.ietf.org/html/draft-ietf-softwire-gateway-init-ds-lite-05
http://tools.ietf.org/html/rfc6342
http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps-08

The charter talks about CGNs but given the recent thread a clarification is
needed if PCP protocol should be appropriately specified so it can work on
wireless/wireline service provider networks as described above.

Can the chairs please clarify the scope of PCP?

If such network architectures are in scope will this be part of the base
spec or can we have a new deliverable on the charter?

Thanks,

Reinaldo


On 11/2/11 5:39 AM, "RJ Atkinson" <[e-mail]> wrote:

> 
> On 01  Nov 2011, at 18:54 , Reinaldo Penno wrote:
>> On 11/1/11 3:10 PM, "Stuart Cheshire" <[e-mail]> wrote:
>>> 
>>> If you want to make the PCP server be different hardware from the NAT
>>> gateway you certainly face additional challenges. That's like making
>>> your DHCP server be different hardware from the device that actually
>>> assigns the IP addresses. The PCP server will need to communicate
>>> with the NAT gateway using some proprietary protocol of your own.
>>> That proprietary protocol needs to be adequate to represent PCP
>>> semantics, or you will have a hard time making it work.
>> 
>> I was actually separating subscriber interfaces from (PCP Server, NAT
>> Gateway). It goes back to my original email that you need more than PCP
>> Server and NAT gateway on the same device - you need subscriber interfaces
>> to be part of this device as well.
>> 
>> If they are, you can multicast packets only on the subscriber facing
>> interfaces associated with the 'NAT gateway' that went down. Otherwise on a
>> trigger from the NAT gateway the subscriber router will need to multicast on
>> all interfaces of all VRFs.
>> 
>> 
>>                                ,------.
>>                               /        `--.
>>                             ,'             `.
>>                            (    Internet     )  +------------+
>>                             `.              /   | NAT A      |
>>                               `------------'  .-' PCP Server |
>>                                             .'  +------------+
>>                                          .-'
>>                     +------------------.'+
>>                     | +--------+    .-'  |      +------------+
>>   Subscribers A.......|        |  .'     |      | NAT B      |
>>                     | |  VRFA  .-'       |   _.-| PCP Server |
>>                     | +--------+       _..-''   +------------+
>>                     | |        | Edge''  |
>>   Subscribers B'''''''|  VRFB  ''Router  |
>>                     | +--------+         |
>>                     | |        |         |
>>   Subscribers C-------|  VRFC  +...___   |      +------------+
>>                     | +--------+      ``-+-...__| NAT C      |
>>                     +--------------------+      ` PCP Server |
>>                                                 +------------+
>> 
>> 
>>> 
>>> The Epoch time is *not* the time since your (hypothetically separate)
>>> PCP server crashed. The Epoch time is the time since the inception of
>>> the current collection of NAT mapping state.
>> 
>> Correct, but my use case was a bit different. Hopefully the picture
>> clarifies. The topology above is very common on both wireless and wireline.
> 
> The picture and description are of some help, but of limited value,
> because PCP does not have the concept of a VRF.  The PCP-related
> I-Ds being discussed here (base specification, Rapid Recovery)
> both are silent about the behaviour of VRFs.
> 
> (ASIDE:  I'll note that the acronym "VRF" is used in a small
> number of IETF RFCs.  It does NOT have the same meaning in
> all of those RFCs.  For example, the "VRF" definition in
> RFC-4026 is not identical to the "VRF" definition in RFC-4364.)
> 
> Any questions about VRFs necessarily will have answers
> that depend upon the details of one's VRF implementation,
> since PCP does not have a standard definition for a VRF.
> For help with how one's VRF implementation relates to
> one's PCP implementation, one ought to look internally,
> not to the IETF.
> 
>>> The Epoch time is a property of the NAT gateway state,
>>> not the PCP server.
>> 
>> Yes, if PCP Server/NAT 'A' above goes down,
>> and we want to use multicast recovery:
>> 
>> - edge router should send multicast only on those interfaces
>>   and VRFs that are associated with the given NAT Gateway
>> - edge router must send a multicast recovery on all VRF/interfaces?
>>   This is what the current text implies (or does not fully specify).
> 
> I think the current text does NOT say what you write above.
> I'll quote what I think is the applicable text from
> the I-D (draft-cheshire-pcp-recovery-02, Section 3, Page 2):
> 
> When a PCP server device [PCP] that implements
> PCP Rapid Recovery reboots, restarts its NAT engine,
> or otherwise enters a state where it may have lost
> some or all of its previous mapping state (or enters
> a state where it doesn't even know whether it may
> have had prior state that it lost) it MUST inform
> PCP clients of this fact by multicasting the UDP packet
> shown below on all multicast-capable interfaces
> on which it accepts PCP requests.
> 
> If you think the current text is confusing, it might be
> more productive if you proposed text that you find more
> clear.  Often, sadly not always, that helps focus the
> conversation.  It is at least worth trying in this case.
> 
> Kindly note that any proposed text ought NOT talk about VRFs
> at all, because PCP does not have the concept of a VRF.
> 
> Also, minimal edits are usually best, as minimal editing
> simplifies attaining consensus.
> 
>> Notice that from a PCP Server/NAT perspective it has only a
>> single interface.
> 
> This is NOT obvious either from your description or from your
> diagram.
> 
> Again, note that the PCP specification is silent about VRFs,
> and does not talk about them in ANY way.  VRFs are ENTIRELY
> a proprietary implementation detail of your system, and are
> NOT part of the PCP specification set.
> 
>> Bottom line, I would like multicast recovery to work (as much as possible)
>> on distributed environments such as ISP edge/core as well. For that, it
>> seems we need some more wording/scenarios on the draft. I can provide text
>> is necessary.
> 
> It is probably helpful if you provide some minimally different
> proposed text, and clearly indicate which existing text you
> propose to replace.
> 
> To repeat the comment above, please do NOT talk about VRFs
> in your proposed new text, as the PCP specification set
> does not contain the concept of a VRF.  Trying to add the
> concept of a VRF to the PCP specification at this late date
> is very likely to slow progress of the PCP base specification
> further.
> 
> Yours,
> 
> Ran
> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp