Subject: [OSPF] Fwd: [L1vpn] Reviewrequested:draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt

From: Acee Lindem <[email-masked]>
Date: Fri, 13 Jun 2008 08:32:39 -0400

Comments from Julien Meuric.

Begin forwarded message:

>
>
>
> -----Original Message-----
> From: MEURIC Julien RD-CORE-LAN
> Sent: Friday, June 13, 2008 10:34 AM
> To: [email-masked]; [email-masked]; [email-masked]
>
> Hi all.
>
> With respect to the v2-based solution, the v3 ID says: "The notable
> functional difference is the support of IPv6." If it's actually the  
> only
> difference (I haven't deeply reviewed the new ID yet), is there a  
> point
> to make the draft Experimental? It is indeed likely to be  
> implemented in
> a longer term than the former one, but it is mainly a matter of  
> schedule
> towards IPv6. As the feature itself should look like the OSPFv2-based
> solution, I'm rather in favor of "Standards Track", but maybe you have
> some other reasons in mind (speed up publishing process?).
>
> Regards,
>
> Julien
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
>
> L1VPN and OSPF working groups,
>
> During the IESG review of draft-ietf-l1vpn-ospf-auto-discovery-06.txt,
> the
> IESG asked the L1VPN working group to consider how to use OSPFv3 to
> provide
> IPv6-compliant auto-discovery for layer one VPNs. They agreed to  
> let us
> do
> this work in a separate draft.
>
> Lou Berger has kindly turned the handle and this is the result.
>
> We intend to move forward toward WG last call with this work quite
> quickly,
> and so we would appreciate you review, comments, and feedback.
>
> To start the discussion, please comment on whether you believe this
> draft
> should be Standards Track (as currently marked) or Experimental? It
> seems
> that there are no immediate plans for any implementation that would
> verify
> that the document is correct or stable.
>
> Many thanks,
> Adrian
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Layer 1 Virtual Private Networks
> Working
>> Group of the IETF.
>>
>> Title           : OSPFv3 Based Layer 1 VPN Auto-Discovery
>> Author(s)       : L. Berger
>> Filename        : draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt
>> Pages           : 11
>> Date            : 2008-06-11
>>
>> This document defines an Open Shortest Path First (OSPF) version 3
>> based Layer-1 Virtual Private Network (L1VPN) auto-discovery
>> mechanism.  This document parallels the existing OSPF version 2 L1VPN
>> auto-discovery mechanism.  The notable functional difference is the
>> support of IPv6.
>>
>> A URL for this Internet-Draft is:
>>
> http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-ospfv3-auto- 
> discove
> ry-00.txt
>
>
> _______________________________________________
> L1vpn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l1vpn

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Pradeep Shastry <[email-masked]>
Date: Fri, 13 Jun 2008 18:06:22 +0530

Hi All,

As per GTSM RFC5082, GTSM is more applicable for directly connected
neighbors and also mentioned that experimentation on GTSM's applicability is
needed for multi-hop scenario.

Assuming that GTSM is more needed for directly connected neighbors and not
considered for multi-hop scenario like V-link, I have a question on
applicability of GTSM in OSPF.

Assuming that we have GTSM sessions for directly connected neighbors and
configure TTL for each neighbors and if you receive a packet with ttl not
equal to 255, drop the packet. Now the question is OSPF can receive V-LINK
packet on the same (any of the) interface. If you apply GTSM then we may
drop the V-Link packet because generally V-Link is more than one hop away.

Will this be an issue or any way to get way with this? Or we have to
configure least TTL of all the interfaces including V-Link (Assuming that
V-Link is at most 3 hop away, then TTL should be configured with 252 for all
the neighbors)? Or GTSM is not applicable for interfaces which belong to
transit area?

Thanks and Regards

-Pradeepa Shastry

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!