Subject: RE: changes in draft-ietf-l2vpn-signaling-07.txt

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Fri, 17 Mar 2006 09:13:55 -0500

Bruce,

[clipped...]

> 
> Let me explain the change. First,  there is an editorial change to  
> remove a dependency of draft-ietf-l3vpn-bgpvpn-auto-06.txt. 

What is the motivation behind removing this dependency?

>That is  
> why I said:
> 
> > That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in
> >    which case it SHOULD be encoded as an RD by placing the value
> > 0x80 in
> >    the first byte of the RD (to indicate the RD type) and the 7-byte
> >    VPN-ID in the remaining bytes of the RD.
> 

This text is coming from draft-ietf-l3vpn-bgpvpn-auto-06.txt,
could you please add a reference to this text for the bgp-ad draft 
such that people will know where this text is coming from.
 
> where as previously there was text that said
> 
> If the globally unique identifier for a VPLS is
>     an RFC2685 VPN-id, it can be encoded as an RD as 
> specified in [BGP-
>     AUTO].
> 
> The non-editorial change is the first sentence:
> 
> > It is RECOMMENDED that a single VPN-ID be assigned to a VPLS
> >    instance.
> 

If a single VPN-ID is recommended then the question is what format
are you suggesting for this VPN-ID? RFC2685?

I think one of the problem of the new text proposed is it makes the 
concept of VPN-ID central to the draft (but without defined it) 
and is confusing on the format of this term. 

Is this draft defining new VPN-ID concept besides RFC2685?
In that case this VPN-ID needs to be standardized as such. 

Hamid.

> whereas previously the draft said:
> 
>     In order to use BGP-based auto-discovery as specified in 
> [BGP-AUTO],
>     there must be at least one globally unique identifier associated  
> with
>     a VPLS, and each such identifier must be encodable as an 8-byte  
> Route
>     Distinguisher (RD).
> 

> That is, in addition to requiring that there MUST be *at least one*  
> globally unique ID for a VPLS, it now says, in effect, that there  
> SHOULD be exactly one.
> 
> The rationale for the change was that, on close reading of the PWE  
> control protocol draft, I realised that some implementations of that  
> draft might attempt to build 2 PWs between a pair of VSIs if the two  
> VSIs had different RDs. Rather than try to change the PWE draft  
> (which was already in the RFC editor queue) I elected to add this  
> guidance - but not a MUST - to the l2vpn signaling draft.
> 
> Since the draft still allows the use of multiple RDs per VPLS  
> instance, I leave it to the WG to decide if the change is acceptable  
> or not.
> 
> Bruce
> 
> 
> 
> 
> 
> 
> 
> On Mar 8, 2006, at 10:10 AM, Yakov Rekhter wrote:
> 
> > Folks,
> >
> >> From 3.2.2.1:
> >
> >    It is RECOMMENDED that a single VPN-ID be assigned to a VPLS
> >    instance.  That VPN-ID MAY be a VPN-ID as defined in 
> [RFC2685], in
> >    which case it SHOULD be encoded as an RD by placing the value
> > 0x80 in
> >    the first byte of the RD (to indicate the RD type) and the 7-byte
> >    VPN-ID in the remaining bytes of the RD.
> >
> > The above is clearly well beyond an editorial change. It was added 
> > after the document passed the WG Last Call. It was added with no 
> > discussion on the l2vpn mailing list, and no consensus of the WG.
> >
> > With this in mind before progressing this document any further I'd 
> > like the authors of draft-ietf-l2vpn-signaling-07.txt to 
> document the 
> > rationale for this change, and for the WG chairs to ask for the WG 
> > consensus on this change.
> >
> > Yakov.
> 
> 
>

---

From: Bruce Davie <[email-masked]>
Date: Tue, 21 Mar 2006 09:03:47 -0500

> What is the motivation behind removing this dependency?

1. To ensure that the signaling draft doesn't get help up by the IESG  
while the fate of another draft (on which it doesn't really depend)  
is debated
2. To make it easier for an implementor to implement the l2vpn- 
signaling spec without having to look up the relevant paragraph of  
another document

> such that people will know where this text is coming from.

There are 2 separate issues here - giving credit to others, and  
enabling the implementor to figure out what to do.

That draft is referenced 3 paragraphs above, and your personal  
contribution to the signaling draft is noted in the Acknowledgements.  
So I feel like I've done OK at making sure your work is credited.

I'm concerned that if I add yet another reference to bgpvpn-auto,  
there is a risk of confusing the reader, who might think that he  
couldn't implement the signaling draft without first refering to the  
bgpvpn-auto draft. (I have in fact encountered this confusion among  
members of the IESG already with the prior reference.)

> are you suggesting for this VPN-ID? RFC2685?

The draft clearly says that 2685 MAY be used and that other schemes  
may also be used.

> In that case this VPN-ID needs to be standardized as such.

I believe the following 2 paragraphs completely specify what sort of  
identifier is needed and provides one concrete example of how the  
identifier MAY be encoded without over-specifying the solution. I  
think the concept of a globally unique identifier is reasonably well  
defined, and the specification of the RD in RFC 4364 provides enough  
detail on how to encode globally unique identifiers as RDs.

    In order to use BGP-based auto-discovery, there must be at least one
    globally unique identifier associated with a VPLS, and each such
    identifier must be encodable as an 8-byte Route Distinguisher (RD).
    Any method of assigning one or more unique identifiers to a VPLS and
    encoding each of them as an RD (using the encoding techniques of
    [RFC4364]) will do.

    It is RECOMMENDED that a single VPN-ID be assigned to a VPLS
    instance.  That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in
    which case it SHOULD be encoded as an RD by placing the value  
0x80 in
    the first byte of the RD (to indicate the RD type) and the 7-byte
    VPN-ID in the remaining bytes of the RD.  However, any method of
    assigning a unique VPN-ID to each VPLS instance and encoding that
    VPN-ID in an RD MAY be used.