RE: [Softwires] Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands overIPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to ProposedStandard

Hi Yakov- 

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net] 
> Sent: Friday, August 25, 2006 11:28 AM
> To: David Ward
> Cc: idr@ietf.org; Bill Fenner; Durand,Alain; IESG; 
> softwires@ietf.org; Sam Hartman
> Subject: [Softwires] Re: [Idr] Re: Last Call: 'Connecting 
> IPv6 Islands overIPv4 MPLS using IPv6 Provider Edge Routers 
> (6PE)' to ProposedStandard 
> 
> David,
> 
> > Yakov, Bill -
> > 
> > Having read the document I have some initial comments. 
> First, 6PE is 
> > an excellent solution. Overstating the obvious (perhaps my greatest 
> > talent), this is a solution for the subset of softwire 
> problems that 
> > would be used for 6-over-4 when the encaps policy is 
> "always use MPLS" 
> > and there are no security requirements. I will leave the 
> question of 
> > 'no security requirements' for this solution to others.
> > 
> > The major deficiency from a softwires vantage point is that 
> the v4 NH  
> > gets encoded in a  v6 format, but semantically it's  v4 and this 
> > encoding trick doesn't work when you're doing v6 over v4. 
> This is not 
> > to say the solution doesn't work but, since softwires has to solve 
> > both v4 over v6 and v6 over
> > v4 (and variants including VPNs); I strongly urge that we 
> don't have 
> > multiple techniques to derive the AF of the NH.
> 
> As we move forward, I agree with the goal of having a single 
> technique to derive AF of the NH within the context of 
> MP_REACH/MP_UNREACH.

Second that ...

>   
> > The current advancement of multiple techniques that require either 
> > encoding or length-check should be cleared up and made 
> obvious and consistent.
> >
> > I recommend some number of bits (or a byte) be used to 
> state clearly 
> > what the AF of the NH is and leave in original encoding. A 
> capability 
> > can be added to make sure that a peer can understand the 
> new bits. Of 
> > course, I am looking for the minimal change to the doc and 
> to BGP but, 
> > this matter needs to be discussed. The assumptions becoming 
> embedded 
> > in the techniques of how to figure out what the actual AF of the NH 
> > could be easily cleared up w/ the suggestion of just very 
> small number of bits and a capability in BGP.
> 
> While having "new bits" may be sufficient, it is by no means 
> necessary. This is because the current/original encoding 
> already provides a way to distinguish between IPv4 and IPv6 
> addresses in the NH of MP_REACH/MP_UNREACH. I am referring to 
> the approach already used in several documents approved by 
> the IETF (e.g., draft-ietf-l2vpn-signaling, 
> draft-ietf-l3vpn-rt-constrain,
> draft-ietf-l2vpn-vpls-bgp) where the NH Length field is used 
> to distinguish between IPv4 and IPv6 as the NH.

In the IETF docs you site, it seems like the use of NH length as a
protocol distinguisher is driven
by the fact that MP-BGP is functioning not as a routing protocol but
rather
as a multi-router distribution vehicle for provisioning/signaling/policy
information.
One must use what fields are available in the MP_REACH/MP_UNREACH even
if the length of a particular
field indicates its type.

With routing protocols I have always assumed that there are explicit
type fields to identify a particular protocol value. 

> 
> And just for completeness, the current/original encoding 
> provides yet another way to distingush between IPv4 and IPv6 
> as the NH addresses - use two different SAFIs to distinguish 
> between IPv4 and
> IPv6 as the NH. However, I am not aware of any IETF 
> technologies that use this approach.

Is SAFI explosion a potential problem? I am thinking we would need
O(X * Y) number of new values where X is the AFI/SAFI carried across the
transport network and Y is the AFI/SAFI of the transport network.

Chris 

>  
> Yakov.
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www1.ietf.org/mailman/listinfo/softwires
> 

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www1.ietf.org/mailman/listinfo/softwires