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

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 21 Mar 2006 10:45:48 -0500

Bruce,

See comments inline.

> 
> On Mar 17, 2006, at 9:13 AM, Hamid Ould-Brahim wrote:
> 
> > 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?
> 
> 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
> 

I understand the goal you're trying to achieve, but I think it would 
have been more appropriate to discuss first with the authors of the 
draft-ietf-l3vpn-bgpvpn-auto-06.txt of that goal such that the 
dependency can be removed in an appropriate way without loosing key 
information. Because what we really are talking
here is to make draft-ietf-l2vpn-signalling-07 as the "standard"
for implementing BGP discovery for l2vpn. I wasn't aware of such change 
was done in the recent 07 draft only after I saw Yakov's email in 
the mailing list.

There are other drafts such as draft-ietf-l2vpn-vpls-ldp-08.txt
that have a section on discovery (section 5) that only refers to
bgp-auto
draft as the discovery for l2vpn. If draft-ietf-l2vpn-signaling-07.txt
becomes the main standard for discovery for l2vpn then even this draft 
needs to be updated. It is certainly a change that impacts other drafts
in l2vpn. 

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

Believe me my question wasn't about personal credit and
draft-ietf-bgpvpn-auto is not just my personal effort,
credit is definitely not the issue here at all.

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

I think this concern can be addressed if we make draft-bgpvpn-auto
explicitly as a framework document for implementing bgp as a discovery
mechanism. That is why I think removing the dependency can be done but
let's
do it in an appropriate consulted way. 

> 
> >
> >> 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?
> 
> The draft clearly says that 2685 MAY be used and that other schemes  
> may also be used.
> 

I think that's the main problem I have with vpn-ids. Why do we need
multiple formats for VPN-IDs to be used in a single solution.
What's the requirement for that?

I understand multiple types for RD since RD is just to
build non overlapping addresses. Suppose one provider use RFC2685 
as the vpn-id format (complying to this standard) and 
the other use some other form then they won't be able to interoperate 
(think about the other issues management, security, etc).

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

Yes. But these are just globally unique identifiers used as RDs.
RD is not a VPN-ID. In fact RD is a concept needed for BGP
discovery, VPN-ID is a concept that goes beyond the discovery, signaling
mechanisms. 

Hamid.

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