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

[Yakov Rekhter <[e-mail]>]

Chris,

> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]] 
> > Sent: Friday, August 25, 2006 11:28 AM
> > To: David Ward
> > Cc: [e-mail]; Bill Fenner; Durand,Alain; IESG; 
> > [e-mail]; 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.  

Are you sure that in the docs I site 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" ?

The reason I am asking this question is that I happened to be a
co-author on one of the docs (draft-ietf-l2vpn-vpls-bgp), and be
quite involved in the design of the other (draft-ietf-l3vpn-rt-constrain).
And in both of these cases the use of NH length was driven solely
by pragmatism, rather than by a rather theoretical (and largely
irrelevant) consideration on whether BGP is "a routing protocol",
or "a multi-router distribution vehicle".

> 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. 

May I suggest that you revisit this assumption, as it clearly
does not match the reality of BGP. 

> > 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? 

Perhaps, but only in theory. Of course, as I like to say while in
theory there is no difference between the theory and the practice,
in practice there is...

> 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.

In the context of IETF the transport network is either IPv4 or IPv6.
Which means that that if one uses two different SAFIs for every
application that uses Multiprotocol BGP (one to indicate IPv4
transport and another to indicate IPv6 transport), then we'll be
able to support 128 of such applications. That seems more than
enough from a practical point of view...
  
Yakov.

_______________________________________________
Softwires mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/softwires