Hi Andy, Please see inline.
Cheers, Ian > On 12 Jul 2016, at 14:48, Andy Wingo <[email protected]> wrote: > > Hi Mohamed, > > Thank you for your response. > > On Tue 12 Jul 2016 13:46, <[email protected]> writes: > >> [Med] Actually, the data model allows to map a B4 to one or multiple >> softwires. >> >> The rationale for using binding-ipv6info as an index is to ease >> enforcing per-subscriber policies (e.g., limit the number of softwires >> per B4). > > I am new to YANG; apologies in advance for making all of the beginner > mistakes. My understanding of the specification > > list binding-entry { > key "binding-ipv6info"; > description "binding entry"; > uses binding-entry; > } > > was that "binding-ipv6info" uniquely identifies the B4 (because it's a > key within the binding-entry list). Is that not the case? If it is the > case, how is it possible for one B4 to have multiple softwires? [if - It depends what defines multiple softwires here. The B4 can have multiple softwires if the source v6 and the v4/PSID tuple are unique. The routing choice for the B4 of which softwire to use for which traffic is local to the implementation and not specified. From the lwAFTR’s perspective, they are two separate binding table entries. The fact that they are going to the same B4 is invisible.] > >>> It seems to me that one CPE could very well have multiple slices of >>> IPv4 addresses. >> >> [Med] That's possible with the current data model: distinct binding >> entries that belong to the same B4 may have distinct IPv4 >> addresses. Whether the same or distinct IPv4 addresses are bound to the >> same B4 is deployment-specific. IMHO, this should be considered with >> caution as it may lead to some applications failures e.g., RTP using >> IPv4@1 while companion RTCP flows are bound to another IPv4@2. > > Indeed. Happily for me though this complexity is on the B4 side of > things ;-) By the time it gets to the AFTR I don't have any sort of > policy decisions to make there. It is a very pleasant standard in that > regard :) > > Regards, > > Andy > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
