Subject: RE: [Idr] draft-lefaucheur-idr-v4nlri-v6nh-00.txt

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Sat, 18 Nov 2006 15:34:26 -0500

In favor. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: Eric Rosen (erosen) 
> Sent: Friday, November 17, 2006 12:48 PM
> To: [email-masked]
> Subject: [Idr] draft-lefaucheur-idr-v4nlri-v6nh-00.txt
> 
> At  the  IDR  WG  meeting  last  week,  we  discussed  
> draft-lefaucheur-idr- v4nlri-v6nh.  I would like to propose 
> now  that this be adopted as an IDR WG document.  Your 
> feedback is invited. 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Bruno Rijsman <[email-masked]>
Date: Sun, 19 Nov 2006 12:04:15 -0500

> now  that this be adopted as an IDR WG document.

I am in favor of adopting this as a WG document.

> Your feedback is invited.

It would good to explicitly point out that the "Extended Next Hop Encoding"
capability is not to be used for legacy address families mentioned in
section 1 which already have some existing mechanism to determine the type
of next-hop (e.g. ietf-l3vpn-rt-constrain).

In section 3 the draft says "However, this encoding has been chosen to
facilitate potential use of a similar mechanism in the future for other
address families."

It would be good to clarify that future drafts for new address families
should consider both IPv4 and IPv6 next-hops right from the get-go and
should provide some mechanism to infer the type of next-hop from the
encoding (e.g. based on length). That way, these new address families will
not need the "Extended Next Hop Encoding" capability.

We only need the capability if we extend some existing draft (which was
already defined, implemented and deployed) with some new type of next-hop in
such a way that it might confuse existing implementations.

To be more "future proof", new drafts might include language such as "If the
length or the format of the next-hop is not recognized, the route should be
declared unreachable but the session should not be torn down."

-- Bruno

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 20 Nov 2006 09:27:22 +0100

Hello Bruno,

> of next-hop (e.g. ietf-l3vpn-rt-constrain).

Right. We've already got some edits in the works clarifying the set  
of <AFI/SAFI> for which the "Extended Next Hop Encoding" is  
applicable (and hence for which it is not).

> not need the "Extended Next Hop Encoding" capability.

Agreed. We'll include such a recommendation.

Thanks

Francois